I’ve used similar solutions to focus an element on mount. Basically, I make the component take a map where :focus-on-mount can be set (defaulting false), and have the parent check some flag in the DB. Since the event isn’t creating a component directly, but by design has a layer of insulation in the form of the DB between it and the view, the only practical solution seems to be to inform the DB of this.

Thanks!

Note that the inner component can set its own ID (to a UUID or something else that is known to be unique), it doesn’t have to be known to the parent or other components of all it’s meant to do is scroll or focus.

I know of two options: 1. re-com-like approach. I.e. all reusable components don't have any idea about re-frame. They just accept ratoms, values, and callbacks. 2. Pass event vectors instead of callbacks. The reusable components will then just dispatch the events when something happens. Same for subscriptions. I use both in my projects - depending on what can be reused. If it's just some simple view (a customized button/input field/etc) then I go with 1. If it's something that uses the same subscriptions and events then I go with 2.

Somewhat relevant discussion with a bunch of ideas: https://github.com/Day8/re-frame/issues/137

Hm, it's not so much a question of components - I think I've got those in hand. My current concern is mainly about things happening in the background of re-frame; events dispatching events, like:

(reg-event-fx ::create-lamb-success
  {:dispatch [::farm/new-lamb new-lamb-id]}

I wonder if passing the events to be dispatched all the way through the API-effect would be workable. :thinking_face:

I think so. It's akin to passing :on-response and :on-failure events to some IO effect. Projects that may be relevant: https://github.com/Day8/re-frame-async-flow-fx https://github.com/ingesolvoll/re-chain

I know that we have https://github.com/Day8/re-frame/blob/master/docs/FAQs/DB_Normalisation.md but the projects listed there fall quite short from what I need. Right now I'm using a heavily modified version of SubGraph (and now there's probably almost no original code left).

hey, author of compound here, we’ve got a new version on the way which is a bit simpler and also faster https://github.com/riverford/compound/tree/compound2 I’d definitely be curious what you might want added to it - people have asked for joins; I’ve been tending to do these in re-frame subscriptions but could potentially add something

Hi! A few things that I find useful: 1. Many-to-many via through tables. That's how it's implemented in regular RDBs. It's useful because apart from just foo-id and bar-id there can be other attributes (e.g. bar-order). 2. Proper relations. I want foo to be linked to bar so I could e.g. get all bars that belong to a particular foo. I want all linked bars to be removed when I remove a foo. I want to make it impossible to have dangling references. You get the idea. 3. Some kind of transactions. The main workflow in the aforementioned app is that user select an entity, edits its details, then saves them. The app tracks the changes (akin to having a transaction), highlights changed input fields (akin to getting current transaction object's contents), displays errors (although validation should probably be out of scope of this discussion), allows reverting back to initial state for one input field or for all of them (transaction rollback) and saving (transaction commit). 4. The data in the transactions should not break the relational model. If I remove something in a transaction, all of the linked entities should be removed as well. Of course, apart from ON DELETE CASCADE there are other strategies. Maybe they can be useful in general. Although I haven't had any need for them yet.

this is interesting, thanks. Seems like a lot of this relates to foreign key type relationships