[snippy]

Thank you for your great explanation. I've read the documentation of re-frame, but I still can't figure out how it deals with reusable components and hierarchies.

Let's say I want to write a reusable datepicker component which sends an event like [:date [2017 1 16]] when the user clicks on that date. How can it send it to the calling component? The re-frame pub/sub message bus seems to be global, but what if I want to have several instances of the same component on the page?

The only solution I can come up with is to parameterize the component on instantiation, so that if I have a "person" component that uses the datepicker to set the day of birth of the person, the date-picker would be parameterized so that it would emit a global event such as [:set-person-day-of-birth <person-id> [2017 1 16]]. Is this how re-frame approaches hierarchies?

[phrygian]

I would say you don't. I think about it this way: use re-frame to write applications, but components must be self contained and have no knowledge of reframe. To do what you asked, I'll pass a function to the component. The function can then make the context-aware reframe call. That way all your component needs to do is to call the passed in function.

[dkersten]

It depends on what you mean by component. Reagent components (ie UI widgets), I agree. Components should be self-contained and as re-frame agnostic as possible. So instead of subscribing to the data they want, they could take in a ratom as an argument (because the subscribe function returns one anyway).

But if the component is larger (that is, not just the view, but also the handlers and subscriptions -- I'd probably call it something else, a service maybe...) then its a bit less simple because not just the view, but also the handlers and subscriptions need to be aware of the "instance" they are running. There's no well defined re-frame solution for this yet.

My favourite solution right now is to have each instance have its own ID as explained here: https://github.com/Day8/re-frame/issues/264#issuecomment-260...

That is, by convention, subscriptions are always [query-name instance-id <other optional data>] and messages are always [message-type instance-id <other optional data>] by convention. This way works quite well, but has the downside that it is by convention and there's no guarantee that other code will do it the same way.

[_vbedegi_]

> There's no well defined re-frame solution for this yet.

FYI, I just tried to address those issues in a small Elm-ish wrapper on top of re-frame

https://github.com/vbedegi/re-alm

[phrygian]

Of course yes. My reply was largely tied to the parent's description of a date-picker component. But for application level components I'd use event names that are unique at the application level that conveys the intended semantics of the event. Everything else becomes an argument to that name, which pretty much aligns with your notion of instance Id et al although I'd be less rigid about the particular structure of the arguments.

[dkersten]

although I'd be less rigid about the particular structure of the arguments.

My reasoning was for conpatibility and consistency. If everyone makes up their own argument structure, it becomes very difficult to maintain and puts the onus on the developers to remember which components use which structure. I'm not really asking for much beyond standardising that the first argument of an instanced event of subscription query is the instance id.