Dismissable alert breaks

[ebellani]

Executing the code at the branch https://github.com/ebellani/om-bootstrap/tree/dismissable-alert-timeout
will produce the exception

random.js:474 Uncaught TypeError: G__14921.set_timeout is not a function

which is the result IMO of this code

(defcomponentk alert*
  "Renders the alert component with timeout mixed in. TODO: This
   should probably use the component macro and be defined inline under
   the alert function. No need for a separate name."
  [[:data bs props children] owner]
  (:mixins m/set-timeout-mixin)
  (did-mount [_] (when (and (:on-dismiss bs) (:dismiss-after bs))
                   (doto owner 
                      ;;  BREAK
                     (.set-timeout (:on-dismiss bs)
                                   (:dismiss-after bs)))))
  (render
   [_]
   (let [classes (t/bs-class-set bs)
         dismiss-button (when-let [od (:on-dismiss bs)]
                          (d/button {:type "button"
                                     :class "close"
                                     :on-click od
                                     :aria-hidden true}
                                    "×"))]
     (d/div (u/merge-props props {:class (d/class-set classes)})
            dismiss-button
            children))))

[ebellani]

This seems to be related to the timeout-mixin, but frankly I'm not exactly sure as of now. Any ideas?

[sritchie]

Yeah, that's right. This is a bug with om-tools's mixins in advanced compilation mode. Check out the "Button Loading State" example text.

To fix it, you'll need to alias that call:

   ;; This is required to get around
         ;; https://github.com/Prismatic/om-tools/issues/29.
         set-timeout (aget owner "set_timeout")

Then call set-timeout as a function instead of .set-timeout as a method.

[sritchie]

Actually, according to @swannodette you can add a line to your externs:

plumatic/om-tools#29

[ebellani]

Another thing, is the order of arguments of defcomponentk alert* correct?
I mean [[:data bs props children] owner] instead of [owner [:data bs props children]]

[ebellani]

btw, the aget doesn't seem to work, since the owner in question does not have that property. Perhaps the externs?

[sritchie]

@ebellani the order of arguments doesn't matter, as om-tools passes the argument vector of defcomponentk onto the fnk macro. What that argument vector is expanding to is:

{owner :owner {:keys [bs props children} :data}

It's just easier to directly write the keys that you want to access.

[sritchie]

@ebellani huh, confused on the aget not working. Is this in dev mode or advanced compilation mode? Can you get the "Button loading state" example from the docs site to work?