Fork me on GitHub

I have a button that dispatches an event that results in a new DOM element. What would be a good way to call scrollIntoView on that element? Note that it has to be called only right after the button is pressed. I don't want to call it on mount since mounting can happen more often than needed.


Right now, the best way I could come up with, is to still use componentDidMount. It would then check some unique ID that I pass into that event and to the component in the atom of all the IDs that I have already scrolled. Really dirty but should work.


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.



👍 4

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'm in the process of trying to split my app up into independent(ish) modules, but I need some events in higher-level modules to happen in response to events in a core module. Eg. updating IDs in otherwise independent parts of the appdb in response to creating something via an HTTP request. Does anyone know of any re-framey solution to that kind of thing?


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:


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]}
where the sheep module shouldn't need to care about the farm, only vice versa.


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:


Heh. I just realized that one of my projects has gotten so complex that now it really needs some kind of a [somewhat] transactional RDB at the frontend. Has anyone ever stumbled upon something like this for re-frame? Or maybe upon something that could be easily adapted for re-frame.


I know that we have 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 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

✔️ 8

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