Fork me on GitHub

Does anybody know why re-frame uses functions behind multimethod instead of using the multimethod directly?


Is there any value in outputing [about-panel] instead of the markup for it directly?


@pupeno: I’m not quite sure if you’re asking why they use [about-panel] instead of (about-panel), or if you’re asking why they’re using multimethods at all. If it’s the former, then check out If it’s the latter, then I think it’s just a clean way of switching on the subscription parameter.


danielcompton: I’m familiar with [] vs () and multimethods and how they work. My question is why use the multimethod to output [about-panel] instead just outputting [re-com/v-box :gap “1em" :children [[about-title] [link-to-home-page]]]


That is, why the second level of indirection there? Is it useful for soemthing?


Don’t think so particularly, other than it being slightly cleaner and more modular. However I didn’t write it, @gadfly361 is probably the best one to ask?


@pupeno: so you can go your own way on this one simple_smile


@mikethompson: if you think it’s a good idea, I can help out.


On another note: is anyone working on a sync approach with Datomic like om next?


The declarative queries part and the client being in control, really makes sense I think, so I’d like to see something of that kind with re-frame


@hkjels: I'm working on some stuff with RethinkDB. It similar in intent to, but will probably come out a bit different


That would be the live-sync part and not declarative queries I guess?


Or the whole concept?


RethinkDB looks pretty cool. Haven’t had the chance to mess with it


@pupeno: I didn't write that code, but be cautious about using "static" lookup datasctructures like say this:

(def  panels  {
      :home-panel home-panel
      :about-panel about-panel
      :default  [:div]})
See: As that ticket makes clear, you can get problems with figwheel The multimethod approach avoids that sort of "static data structure" issue with figwheel Just a thought.


My point is to keep the multimethods, just not the functions.


@hkjels always keen for help simple_smile


@mikethompson: OK. I’ll do some sketches 👍 If you have any thoughts at all about logo, symbols, colors etc, let me know


@hkjels: SQL queries are declarative too :) it's going toward the same goal, but it will probably end up looking quite different


That’s true. I just think Datalog is abit more future-proof. If you have a look at atomic and datomic-junk, you can see how minimal the syntax could be in best-case


or the lack of syntax simple_smile


Hello everyone


I'm just beginning to learn re-frame, and I'm wondering if there are any drawbacks? I have only heard praise so far simple_smile


@reefersleep: welcome! I’m afraid your question is too general. re-frame library is an implementation of general re-frame pattern. there are probably some drawbacks when applying it in concrete situations. one trivial drawback with re-frame library is that you are adding yet another dependency to your project, you have to learn the pattern and use it properly. there might be some performance or flexibility concerns as well. for example re-frame library expects you to have only one “global” app-db and it depends on reagent. relaxing this is possible, but involves some work.


is there a reason there's no bundled macros for views/handlers/subs ?


@darwin: cheers simple_smile The things you mentioned do not seem scary to me, which is good!


@pupeno @danielcompton @mikethompson regarding routes in the template: the original impetus was to play nice with figwheel. And after doing it that way, it does feel cleaner to only put a reference in app-db instead of the whole function itself (feels more 'Elm'y)


@reefersleep: one limitation I do see is that re-frame encourages a top-down approach to building your app: all your components leverage a single toplevel global context, which may make them less 'portable'. I don't really see this as the drawback, more like a limit of its application space.