Aurelia store questions

Help Requests
#1

I briefly looked at the store plugin a long time ago and gave up on it quickly because I ran into issues and it didn’t really solve any problems with my application that I was building.

I now have a need to use it or something like it for a new feature so I am giving it another chance. After fighting with package versions in my yarn workspace I’m finally up and running.

I know the overall idea is to have 1 store for the application, but I’m wondering if there is a way to solve my problem. I have the overall application that can exist in the store object. The bulk of the application does not need to be history aware, but I have one component where history would be very useful. I have a complex configuration system that users will be making changes on a series of forms. All while the main application state can still be changing (moving forward) and it will change often. This form doesn’t become part of the “State” until all configuration is done and a post processing on the server side is performed. While the user is configuring this form I would like history for the form only. Is there way to do this or is there a way to have multiple stores. The history of this sub section can not roll back the primary state which could move forward many versions in between the user actions.

I feel like I may have asked this question before…

#2

So from what I understand you have a section which needs undo/redo features and once complete goes into the store right? Typically I would say this sounds like component local state. If you want though you can of course use another instance of the store (new Store(…)) for this sake.

To give you a sample where I used a second store instance is the log panel of the IDE I’ve worked on. While the whole IDE is part of a default single store, the log panel created a second instance due to high throughput and history support. The only difference here is that this was purely ephemeral state which didn’t come back into the global one. So you would have to make sure to store it with a global stores action and on a new start rehydrate the initial state of the substore to the previously stored value.

1 Like
#3

Thanks.

The “form” section I’m talking about actually comes from a plugin. The plugin is a factory that creates a new instance of the form logic so what you are suggesting should work perfectly. Each form can have it’s own history. That will be one of the last things I’ll be working on as it will require some re-working of how the form controls get created. I just didn’t want to start down this path of using the store more widely in my application only to hit a road block.

I just wasn’t sure if store plugin configure time was the only time a store could be created.

#4

If my history aware functionality is actually in a plugin, can the plugin have it’s own store while the main application has it’s own without any special configuration?

Also, this is due to my lack of knowledge using the newInstance, how do I create this new instance with history enabled and give it a default state. I Have a new store working, but no initial state which is okay, but it would be nice to have an empty valid state object.

When doing this, I can see the initial state on the store’s initial state object, but it is never assigned to the present state so my addWord action fails and obviously any bindings attached to this object don’t work.

    constructor(
        @newInstance(Store, { initialState, history: { undoable: true } }) private store: Store<StateHistory<SubState>>
    ) {
        this.store.registerAction('addWordAction', addWordAction);
    }

export const addWordAction = (currentState: StateHistory<SubState>, word: string): StateHistory<SubState> => {
    return nextStateHistory(currentState, {
        words: [...currentState.present.words, word]
    });

    // return Object.assign({}, currentState, {
    //     past: [...currentState.past, currentState.present],
    //     present: { words: [... currentState.present.words, frameworkName] },
    //     future: []
    // });
};
#5

Ok I’m unsure what that newInstance decorator does never saw it. For your second instance I’d go create directly/manually an instance of the Store class. You’ll see that the constructs accepts a config object. After that, if you need, register the new store with a different key via DI. But since this one is mostly local I doubt you’re gonna need a DI.

As for usage in plugins, I’m unsure but I would assume that either the plugin or your app would overwrite the same DI key so you’d most likely have issues.

1 Like
#6

That works, thanks! I’m not sure if I’d need it in the container, but good idea.