Question: Best practise pattern for list -> record state management

[domingoladron]

So in reviewing the docs and examples, the basics make 100% sense. When dealing in:

1. A single value (clickCount)
2. A static list of values (IEnumerable)

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 individual SomeWidget?

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

[mrpmorris]

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.

[domingoladron]

Oooh, interesting. Where can I find more information on the IStateSelection interface? This sounds precisely what I'm chasing.

Cheers for the quick response.

[mrpmorris]

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.

[domingoladron]

That's awesome! I'll take it for a test toast and see how I go.

Cheers for the great response

[jjhayter]

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.

[mrpmorris]

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

[jjhayter]

Ah yes my bad for not being more clear, the attribute has a parameter to specify the number of seconds.