@mihaelkonjevic Do you absolutely prefer a system where the subscriptions decide what needs rerendering as opposed to the commands declaring somehow what they are changing? If you know what mean

hm, I’m not sure I understand

Well, reactions return some data, right? They rerun if that data has changed. This happens every render. I'm thinking what it would look like if instead of subscriptions, commands would decide what needs rerendering. Commands declare what they change.

so you can manually re-render some component?

Something like that. More so that you can say what the command wants to rerender when you know it won't change something else. Hm... yeah, I'm not saying this well

I'm thinking that something like this might be pluggable

so

what is the problem you’re trying to solve?

Components could declare when they send a command which subscriptions the command affects so that other subscriptions would just take the cached value. Mostly trying to reduce the number of unnecessary rerenders when I absolutely know only one of them had to happen. I wrote this example in the reagent channel

Hm... so with reactions. If I have a list of components which can either be in view or edit mode. they all deref a subscription to find out whether they should be edited. when I just had view they all just received an id and rerendered when the data associated with the id changed but now they all depend on knowing which id is being edited so when the id that is being edited changes, they all update I suppose I'm asking if there's a way to make this more fine grained to more explicitly decide when to rerender based on current and previous value of reaction (edited) so only rerender if id of row is the same as the edit id

I think you can use reactions inside the reactions

so you don’t deref the whole app-db if you don’t want to

hm... right. Yeah, this might be it. I'll try something

do you have a performance problem somewhere? If you can reproduce it in some example, I could try to see if I can help 🙂

Yeah, it's not really extreme. It takes a bit longer for a row to change into an edit row than I would like. Thanks for the offer, you're very helpful, I'll try to reduce the example 🙂 Theres 85 rows. They're semantic ui table rows using soda-ash

Granted, this computer is getting a bit bogged down and it's not the production version of react

I’m not familiar with the semantic ui API, but it could be possible that it’s doing re-rendering when it’s not needed. I’ve had similar issues with material ui and reagent. It’s hard to get it right because when you cross the border between reagent and normal react, things can get weird

Might be. Perhaps I should try the same table with just classNames for the css.

I mean, it's not dreadfully slow. 200ms on my relatively bogged down computer and the develop version of react . But I'm being cautious.

When the row is actually being edited it's fine too, because the edit id doesn't change. Just the part when a row changes into an edit row

causes a reflow as well, I think

Actually a couple of different refactors to the subscriptions would all solve it, I think.

Em... so @reefersleep solved the problem for me in the reagent channel. I just need to return a boolean from the subscription instead of the edited id.

awesome!