Updating the value triggers an update for components which only consume the setter
janis-kra opened this issue · comments
When a component (e.g. a TextInput) consumes only the setter for some property (e.g. setText), fleux will trigger a re-render to the component each time it calls the setter. Not quite sure if this can be useful at times or if it's just an error.
Checking for changes via shouldComponentUpdate does not seem to work in that case
It is possible to specify keys to be read and keys to be written from/to the store separately:
withState([toBeRead],[toBeWritten])When a key is specified as write-only, the component will not receive updates if that key's value in the store changes.
Two things that need to be done though:
- Add that information to the README
- Reconsider the API. Specifically this: There is not really a reason to take read-only access to a key, since a component can just not use the setter. Only the other case makes sense, but then you would likely end up with frequent occurrences of
withState([], ['foo']). If the first array is going to be empty in most use cases for this API feature anyway, then it should not be there. Easiest fix for this would be to swap the "keys-to-be-read"-array and the "keys-to-be-written"-array around. Thoughts?
Switching the order of getter and setter parameters in withState seems like a good QoL improvement, yes
Ok, I will switch the order around (kind of a stupid breaking change sadly) and add some more tests related to the supply of proper arguments to withState and related to its behavior when read-only/write-only props are connected.
On a somewhat related note see #5
In planning out how the API will evolve in the future I came to have second thoughts regarding swapping readable and writeable keys in withState's signature. Generally, I prefer to specify readable keys before writeable ones (which was my initial intuition anyway) and I feel this is what users would expect.
Since I plan to add additional functionality to fleux which resembles some of Redux' features (also see #5), swapping the order here would result in an API that is needlessly inconsistent with Redux.
Given that the tradeoff is between consistency with developer expectations on the one hand and a (unconfirmed) assumption regarding a minute QoL improvement on the other, I tend to opt for the former.
Since I currently have no idea how to satisfy both sides of this, I have to assume that after swapping the order now to be "writeable,readable", I would need to potentially swap them back later, which I consider to be even worse.
If no idea comes up of how to solve this any other way, I will not swap the order of the arguments. What I can do, is to allow an empty array of readable props to be replaced by null to allow for a more explicit usage of the API.
Tests also still need to be added regarding the different combinations of arguments for withState and the correct behavior for read-only and write-only keys.
Information about this behavior has been added to the README and tests have been created for this kind of usage of withState.
There should not nothing more to do or discuss here.