Well, I was wondering if the framework could benefit from using some special tags in the views for the if and the for. I am thinking that more things could be simplified in a declarative way if we have them. (but I have to say that re-frame already make things very simple)

Precisely, I was thinking about implicitly deducting subscriptions in the views just by analyzing what data is used and where.

My goal is to have the views as simple as possible so that young children would be able to use re-frame -OR- something that macro-expand to it.

Did anyone tried to implement that sort of thing? If no, I may give it a try.

@vincent.cantin you can already write this kind of code:

(for [todo @(subscribe [:todos/visible])]
  [:p (:task todo)])

How would you go further in deducing which subscriptions are used? It's an interesting idea though

I am not sure at the moment. I will try to make a concrete example and come back with it.

I like the ELM way to pass the state to the view function from its root - it is simple to understand for kids. So maybe something like that, with the addition of being able to infer the data needed to display the views, so that this need can be communicated to a remote server for automatic data fetching.

Maybe having the user write a plain old clojure function, and then have a macro transform it into re-frame code.

@vincent.cantin 1. View rendering triggering remote data fetch is not idiomatic re-frame This FAQ covers some of that territory https://github.com/Day8/re-frame/blob/master/docs/FAQs/PollADatabaseEvery60.md 2. re-frame currently contains no macros. Obviously macros have great value in certain circumstances, but they aren't the first tool i reach for. 3. I believe there's a case for a reg-view kind of function

reg-view use would look like this:

(reg-view 
    :a-view-id   
    (fn [XXX]   ....)         ;; <--- input signal fn much like the one in reg-sub 
    (fn [YYY] [:div ....]))     ;; actual render function, much like the computation function in reg-sub 

THEN ...

with a change to Reagent ... you could create your views likethis

(fn [YYY]     [:a-view-id  other params])

Note the use of :a-view-id registered previously by reg-view

Anyway, that the direction my thinking normally goes in

On other matters ... what I'm currently puzzling about at the moment with re-frame is what might be called the Higher Order Behaviors problem - HOBs (I'm a big believer in pretentious terms) Event handling is the unit of behavior. An event happens to convey user intent, and the application executes behavior necessary to fulfill that intent. But there are often higher order behaviors that span multiple events. Take something as simple as making a server request: 1. The twirly thing as to be displayed. 2. The HTTP GET has to be made. 3. The application is then in a wait state. 4. But not wait too long, there should be a timeout. 5. And then there's different things that happen depending on the outcomes: timeout, success, failure 6. Take down the UI twirly Now we're spreading behaviour across multiple event handlers. I don't like that. We're also into the domain of FSM and yet so many have tried with FSMs and it never seems to work out well. Would we better off using Behavior Trees (an alternative to FSM)? Or maybe CPE (complex event processing) Or maybe a redux-sagas-esq solution but based on core-async instead of generator fucntions. (I'm not keen) Anyway, is where my attention is these days. But it is gentle attention. I wouldn't say I'm actively ripping the roof off this problem.

So, that's an open problem. BTW, HOBs can be big. My server request example was intentionally small. But imagine a FSM which captured all the major transitions in your app. Evetns act as "triggers" for this FSM. The FSM itself produces effects

@mikethompson Thought about using rules for that https://github.com/cerner/clara-rules?

@kenny Yes, there's https://github.com/CoNarrative/precept as POC

@mikethompson You made me look up “behavior trees”. 🙂 Ah, so that is what I did with by (virtual) RoboCup soccer players! It worked great. My tree was just one level: the player decided on an objective (such as “tackle opponent”) and that expanded into so-many sub-objectives such as approach opponent then kick ball, all involving turning, moving. As each sub-objective was achieved the next became the “current”. If an achieved objective was lost (the opponent spun away) we reverted to reacquiring that achievement. And of course the entire larger objective could become irrelevant if they whacked the ball clear away. Then we looked for a new objective. And, yeah, it was built as a tree so no reason the depth could not be greater. So any objective had an action function to achieve it, an achieved? function to determine that, and an abandon? function to decide that (with abandon possibly happening at a higher level while a deeper subobjective was happily being pursued. Go for it!