Local Storage middleware include example of when to register it

[baerrach]

I'm submitting a feature request

Current behavior: In https://aurelia.io/docs/plugins/store#default-middlewares for The Local Storage middleware the info box gives a great hint about not registering the Local Storage middleware at startup, since that will just save the initial state into local storage.

It recommends to "make sure to register the middleware just after the initial state has loaded."

But state doesn't have any lifecycle bindings.

Should this be placed into the bind() method? What happens if I am using the connectTo decorator?

Extending this infobox with an example would be super helpful.

[EisenbergEffect]

@zewa666 Do you have a few minutes to extend this section of the docs per @baerrach ‘s suggestion? He’s a new user coming to Aurelia and has been helping us to improve the docs 😄

[zewa666]

Oki doki will do

[zewa666]

@baerrach the story as stated will startup with a intial state propagation, that is once you setup the plugin in your main.ts. Depending on how you build your app there are multiple ways to solve that part as the correct timing is heavily dependent on your app. E.g there might be a wizard/login popping up first and only after that you enter the actual app where you'd want to kick in the localStorage. So it's a bit hard to give a generic solution.

The most generic one, for a simplistic app would be to register the middleware only after the first state got dispatched (namely the initial state).

constructor(private store: Store<State>) {
  this.store.state.pipe(take(1)).subscribe(() => this.store.registerMiddleware(localStorageMiddleware, MiddlewarePlacement.After, { key: 'my-storage-key' });)
}

connectTo ain't gonna play along with that at all since it's meant to setup a general subscription without the chance for fine-grained control.

What is your thinking about this @baerrach? Go along and just post the above sample? In this case I'd convert the info box to a normal text.

[baerrach]

The problem also includes @connectTo as it feels like an easy win, but doesn't look like it will scale as my app gets more complicated.

Its referenced an awful lot prior to the problem of local storage of state.

It would be great if there was some way to fix the problem using @connectTo somehow. It is enough to include your thoughts on a simple generic solution and hints that a more complicated app might need to hook in at different points in the lifecycle.

When that happens does that mean I need to manually recreate the @connectTo help?

What other "eject" points are people going to hit with @connectTo?

If I'm always going to be ejecting then I wonder whether its worth even starting with @connectTo. I don't have an answer for that, I'd be leveraging the wisdom of Aurelia experts.

[zewa666]

Well its a bit of a mixed feeling here. People are wanting to abuse @connectTo for something it's clearly not. Its essentially a shortcut which does save you writing a bit more boilerplate, makes sure you don't forget to unsubscribe and that's it. The given solution from my previous comment still also applies to using connectTo. Nothing hinders you to create additional subscriptions. Addtionally, by using take(1) you also don't need to care about unsubscribing as the observable will be auto-disposed.

The question about ejecting goes more towards your use cases. I'd say, following along a pareto 80% of your VMs are going to be small, so connectTo is certainly a good fit. But for specific parts, e.g the App.js/ts where you'll likely going to do more stuff you most likely will sooner or later switch to the manual subscriptions.

My personal opinion? Always manually subscribe and be disciplined enough to handle unsubscriptions ;)