You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While I wouldn't mind such API, there has been questions around the constrain of bundling of too many actions on store creation, and the fact that such pattern could not only increase bundle size but also cause unnecessary circular imports.
So, if we were to think of some better APIs for actions, I would probably move towards decomposing them and making them a per-hook:
conststore=createStore({ initialState });// no actionsconstuseMyStore=createHook(store,{actions: ... });// specific per hook
or via dispatch like API at the consumer location:
import{action,useMyStoreAction}from'./my-store'// ... inside the componentconsttriggerChange=useMyStoreAction(action);
or
import{useDispatch}from'react-sweet-state'import{store,action}from'./my-store'// ... inside the componentconsttriggerChange=useAction(store,action);
or
import{useMyStore,action}from'./my-store'// ... inside the componentconst[state,dispatch]=useMyStoreViaDispatch();consttriggerChange=()=>dispatch(action(...))
The benefit of forcing the import of the action on the consumer side is that it makes more explicit the dependency.
The per-hook pattern can be a good way to enable this decomposition when needed, while the dispatch exposes a bit more of the implementation detail... Unsure about the best path forward.
Splitting actions from state was always my first preference, but I dont see a good usecase with action being "reused" for multiple stores. This defines the "type flow" as store -> action, which is roughly the opposite of the current configuration.
Ie option 1 and 2, but not 3 and 4 are they cause "store to meet action" in the user space.
// option 1.5, right in the middle of 1 and 2constuseMyStore=createHook(store,action);
With actions being defined aside of
createStore
it might become a little tricky to type them.In many cases one had to write something like
The modern way to write the same with less TS involved can use
satisties
operatorWorks, but is it making anything better?
what about creating a helper function
createActions
in the form ofThat simple, the same interface as
createStore
accepts.This fill change action definition to
Something like https://www.typescriptlang.org/play?#code/ATCWDsBcFMCcDMCGBjawDK1LsomAeAFRz2gD5gBvAKBBAApxoB3EmALmAAVFZJREAGyJtyASk4A3APagAJgG5awAL7VlkAJ4AHNAHEsokbhgUAvMHpjgZigCVoiOdPCDNx0mSUadaHNNhoAEFkfhcg7VAPUxsqZRAAZ0MTaE5MbBTo8iU6YABzZNJOAwzSLK944DlQBO08ZAALTiJgaAAPGHA5BOAQsPAsgBpgRHBNYdHNMjJ6SpAUfsIGgFdwAGtOQkrrW2AHSGXYcEJfIgqQFW8QLV1e0NAXfEriFMHngGEXXAg4LlhpbQ9CwyeRvXKEfaHcAANSEyzQwNkcmAAB9uP8ALY1aD4EFyMjKcyWSqISJpSABYL3cKRcpgujIL6IH6wP4AhKbT5QZlMVn-QHKHYUCFYKGwwTwq7AG5oPoPY4rdZPcGiekgQhylw9dqdbp7aCM2ByfAJSCwCB5YaahWrNZDYAa6ngBLTQmxegAOi9vDyHJGYyFd369smEzGFWojOdkGAyECpGtQKyrQ60C6PWkACMAFYGyAzCTAIiJlO6noOQ3G03m8CWoPypa2+2O-ou6b0Bbyv0truBzta7xR03S6DDixxxwwRP4ShtdjVi0qAv0GjXUeQdhWEC7FdJUowFSBveiFdzgCMw007AATIfqIeFEA
Wondering if with modern TS we can remove the first function call, it "bind" State variable.
The text was updated successfully, but these errors were encountered: