Discussion/Sharing: my basic state source generator

[zbecknell]

I'm really enjoying using Fluxor. One thing that's maybe a bit difficult for my team is folks dealing with the amount of boilerplate necessary to create new features. Tonight I created a basic source generator to get a useful beginning setup that can make Fluxor truly boilerplate free:

https://gist.github.com/zbecknell/7cd0b1d0caf293e19545210f4e7cb014

This generator just looks for the [FeatureState] attribute and creates a {StateClass}.Update(IDispatcher dispatcher) extension method.

Adjust your state and call the Update() method on the instance. Easy peasy. This is really going to be enough for most of our use cases.

[mrpmorris]

Could you provide an example of its use please?

[zbecknell]

Sure thing. Let's take the basic Counter example.

Here's our state object, fully ready to use with the source generator:

[FeatureState]
public record CounterState
{
    public int ClickCount { get; init; }
}

Rather than create an action, I can use the relatively dumber Update() method I've generated to increment the count:

[Inject] IDispatcher Dispatcher { get; set; }
[Inject] IState<CounterState> StateAccessor { get; set; }
CounterState State => StateAccessor.Value;

private void IncrementCount()
{
    var state = State with { ClickCount = State.ClickCount + 1 });
    state.Update(Dispatcher);
}

Is this a "good" thing to do? Not sure. I'm not deeply familiar enough with flux patterns and related things to know if this is stinky code, but it works, is simple, and lets me share state and not worry about whether my components are properly rerendering on state changes.

[zbecknell]

And to clarify, I just felt like sharing this because I happen to like it. I'm not suggesting it or something like it gets added to Fluxor, but I bet you and other smarter folks will find some cool ways to use source generators to reduce boilerplate in a smart way. The more I use them the more I'm finding repetitive patterns to generate away.

[mrpmorris]

This isn't a good thing to do. Dispatch is meant to declare the intent, not the outcome.

You are putting the reducer logic into the consumer. You'd have to repeat that some logic everywhere you wanted to do the same thing, and that's the point of having reducers, because they are a single-point of code to react accordingly.

[zbecknell]

Right, I figured this is probably stinky. But, alas, it works for my use case. For rough, getting started, type of work, I think it'll suffice. And sometimes that's all that's needed even into the future.

Edit: Really what this is is hitching a ride with Fluxor to have a shared state store that auto-renders subscribers, rather than anything to do with the flux pattern.