Closed domingoladron closed 2 years ago
If it is something completely different then it's a new feature.
If it's the same thing and there are lots of them (e.g. lots of instances of a widget) you can have your state as an ImmutableDictionary<Guid, WidgetState>
Your individual components can inject IStateSelection<ThatFeatureState, WidgetState>
and then call the Select
method on it in OnInitialized
to specify which widget state you are interested in.
Actions would need Guid WidgetId
or something on them.
Oooh, interesting. Where can I find more information on the IStateSelection interface? This sounds precisely what I'm chasing.
Cheers for the quick response.
The above is literally all the info you should need.
1: Inject it
2: in OnInitialized
call the Select
method on the interface
3: consume the .Value
in your UI
If you are descended from FluxorComponent
then StateHasChanged
will be called automatically.
That's awesome! I'll take it for a test toast and see how I go.
Cheers for the great response
I would use the StateSelector as part of the Active Record pattern. If the widget involves lots of text ie description don't forget to add some debounce to it, basically so it doesn't update too often.
Just to make sure you know, Fluxor has a kind of debounce built in.
Debounce alone was not good enough, because lots of frequent updates would result in the UI never getting updated, so I implemented a kind of sampling instead.
1st update = immediate any updates within X time = silenced Every X time you get an update notification
Ah yes my bad for not being more clear, the attribute has a parameter to specify the number of seconds.
So in reviewing the docs and examples, the basics make 100% sense. When dealing in:
This is all quite clear.
However, what is unclear to me is say I have
IEnumerable<SomeWidget>
and my use case is I want my customer to be able to do CRUD operations on said list. So now you have the List of SomeWidgets, and also you now have the possibility of Editing / deleting / adding a single SomeWidget to/from the IEnumerable. Right? Standard data manipulation of values in a list.So, from a Fluxor point of view, are these part of the same UseCase (that is, using the same State, Reducer, Actions, Effects, etc) or do you have one Use Case / State for the
IEnumerable<SomeWIdget>
and another Use Case / State for the individualSomeWidget
?There may be a doc somewhere which describes the appropriate means of structuring this kind of data manipulation in Fluxor / Redux, but I can't find it. I was wondering what patterns you would use for this kind of data structure.
Cheers