How to organize Redux state for reusable components? -
tl;dr: in case of reusable component has complicated logic managing own state (think: facebook comment textarea autocompleter, emoji etc) how 1 use store, actions , reducers manage state of multiple instances of component spread across whole website?
consider real-world example official redux repo. in have:
- a repopage, displays list of users have starred particular repo,
- a userpage, displays list of repos starred particular user
- a list, generic enough can display list of users or repos, provided
items
, wayrenderitem
. in particularrepopage
usesuser
component display each of users starred repo, ,userpage
usesrepo
component display each of starred repos.
assume want all of state in redux.
in particular, want state of every list on every repopage , userpage managed redux. taken care of in example, clever three-level deep tree:
- at top level key says kind of component data (in example called
store.pagination
) - then there branch each particular type of context in component can (
store.pagination.starredbyuser
,store.pagination. stargazersbyrepo
) - then there many keys there unique contexts (
store.pagination.starredbyuser[login]
,store.pagination. stargazersbyrepo[repo]
)
i feel these 3 levels correspond to: component type, parent type, parent id.
but, don't know how extend idea, handle case in list component had many children, state worth tracking in redux.
in particular, want know how implement solution in which:
user
component remains intactrepo
component has button toggles background color- the state of each
repo
component managed redux
(i'm happy use extensions redux, still use reducers, don't want go "just keep in react local state", purpose of question)
my research far:
- it looks in elm actions (messages) algebraic data types can nested in such way, parent component can unpack "outer envelope" of message , deliver inner action intended child child reducer (updater).
- since convention in redux use string type of action, natural translation of above idea use prefixing, , seems prism (foremly known redux-elm) does:
action.type
comprised of substrings tell path through components' tree. otoh in this comment prism author tomkis explains important part of elm architecture redux missing composition of actions - the 2 above approaches seem expanded versions of approaches described in reusing reducer logic
- i haven't grasped how redux-fly works internally, seems use payload, not
action.type
identify component instance mounting path instore
corresponds path in components tree because of way constructed manually components - winapi, me seems quite similar redux if squint, uses unique
hwnd
identifier each control, makes super easy check ifaction
intended you, , decide should state instore
. - the above idea lead described in documentation suggestion/discussion: reusing reducer logic each type of component has own flat subtree indexed unique id.
- another idea descibed in linked thread linked above write reducer particular type of component once, , let reducer parent component call (which means, parent reponsible decide in store state of child located - again, seems similar elm architecture me)
- a interesting discussion more on reusability custom components in details of proposal vary similar 1 above presented
- in particular above discussion contains a proposition user nav, organize store tree recursively in such way, state of component subtree in 2 kinds of branches: 1 private stuff, , other "tables" of child components, each class of child component has own "table", , each instance of child has unique key in table, state recursively stored. unique keys give access these children stored in "private" section. similar how imagine winapi :)
- another elm-inspired proposition user sompylasar same thread use actions contain actions children payload in "matrioshka" style, in opinion mimick how algebraic types constructors nested in elm
- redux-subspace recommended in discussion global actions prism, library both elm-inspired , lets have global actions.
Comments
Post a Comment