On Sun, May 11, 2014 at 4:32 AM, Christian Johansen <[email protected]>wrote:
> Hey, > > I've been playing around with Om a bit lately, and have done a couple of > talks on it (more are scheduled), and showed it to other people in other > contexts as well (including a Norwegian language screencast). Based on my > experience thus far, I have some questions about a few APIs that seem like > they could be a little more approachable. Maybe I'm doing it wrong, or > missing some reasoning. > > > - Using JavaScript objects for component props. Not a big deal, but I > don't really understand why this is necessary? It makes for a trap that's > rather easy to fall into, and when you do, it fails silently (i.e. the > dreaded "nothing happens, no errors" situation). Is there a compelling > reason for why component props aren't ClojureScript maps? > Converting ClojureScript maps to JS objects is not efficient. Initial renders might be quite large. > - DOM components not accepting lists of child components. This makes the > DOM component functions compose poorly with lists of children, which, in my > experience, is by far the most common case. In practice, most of my calls > to DOM component functions use apply. Would it be possible to amend the API > so that DOM component functions can take a list of child components? > As with the previous point this falls out the fact that we just use React DOM components directly. I'm not just not interested in providing something different over React's DOM bits. > On a related note, the build/build-all differences seem unnecessary to me, > and personally, I would prefer a polymorphic build for the same reasons. > This is mostly because of argument order issues. I don't feel strongly about it and no one has proposed how they might be unified. > - om/transact! is conceptually very similar to clojre.core/swap! but the > APIs are slightly different, due to the `korks` argument, and due to > transact! not supporting additional args. This has burnt me many times, and > I don't feel like the korks argument is a good enough reason to sacrifice > an API consistent with swap! But maybe I'm missing something here - will > (om/swap! (get-in cursor korks) ...) always be the same as (om/swap! cursor > korks ...)? If not, then I understand better why this API is the way it is. > transact! works the way it does so it can track the path that changed - pretty useful in conjunction with :tx-listen. That said this may change in a future version of Om as we look for better tools for modeling application data - i.e. DataScript or something like it. David -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
