Change handler not firing on change - Aurelia-Store

Help Requests
1

I am trying to not force the setting of a variable in the store by hand by using the onChanged part of a @connectTo, but the newState and oldState are undefined each time?

(wlTypeRadio is the radio button I am trying to get the new value from)

Here is my connectTo

@connectTo({
    //target: 'currentState',
    selector: (store) => store.state.pipe(pluck("wlTypeRadio")), // the complete state if you need
      onChanged: 'changedHandler'
  })

This is my change function:

    changedHandler(newState, oldState) {
        // notification about new state
        console.log('newState', newState);
        console.log('oldState', oldState);
      }

Any insight would be appreciated.

2

I’m not sure what exactly you’re trying to do, can you describe in a bit more detail? How are you dispatching your action with the new value?

3

I have a radio button (worklist_type) that I am displaying in the view model like so:

<label repeat.for="wl of worklistType">
                                    <input type="radio" model.bind='wl.value'
                                        id="worklist_type"
                                        name="worklist_type"
                                        onchange.call="changedHandler()"
                                        checked.bind="state.searchObj.wlTypeRadio">
                                        ${wl.display}&nbsp;
                                        &nbsp;
                                </label>

What I want to do, is when the worklist_type changes, is to set some of the fields in the form as disabled or empty.

I was doing it like this:

<label repeat.for="wl of worklistType">
                                    <input type="radio" model.bind='wl.value'
                                        id="worklist_type"
                                        name="worklist_type"
                                        onclick.call="setBalanceFields()"
                                        checked.bind="state.searchObj.wlTypeRadio">
                                        ${wl.display}&nbsp;
                                        &nbsp;
                                </label>

(Using onclick)

and then in the js:

    setBalanceFields()
    {
        var form = document.forms['searchform'];
        
        if (form.worklist_type[0].checked)
        {
            this.state.searchObj.wlTypeRadio = this.worklistType[0].value;
            form.balance.disabled = false;
        }
        else
        {
            this.state.searchObj.wlTypeRadio = this.worklistType[1].value;
            form.credit_limit.value = '';
            form.balance.value = '';
            form.balance.disabled = true;
        }
    }

But it seems like me forcing the change of the wlTypeRadio in the state itself is the wrong execution of what should happen?

4

alright now I see. So you really never should directly manipulate the state but instead use actions which you dispatch. See this docs entry explaining its purpose.

My question is, whether what you’re doing here is just an ephemeral state, that is only necessary for a quick specific action and only a single custom element. If so, don’t put it into the state in the first place. The Store approach is meant for data that you’re going to share across multiple custom elements and want to have one common place to store them and only modifying them via actions.

5

The reason I am using store for the search object is because I need to have it available after you click away from it and then return.

Like if they click on a search result to pull up a customer, and then want to view search results again. It keeps the form in state too, so they can see what they searched for the previous time.

6

You can do that, but you should still dispatch actions to modify the store and not bind anything directly to it. It’s always made more sense in my head to just think if I need to respond or read a value in multiple places in the application - if I do, then it’s a viable store item. If not, then don’t forget you can use something like window.sessionStorage to help maintain some sort of temporary state.

Don’t know if that helps at all?

7

Thank you for that. I figured out what to do for now. When my changed handler fires, I can see that it is actually updating the wlTypeRadio without me having to touch it, so it’s doing what I need. I just didn’t understand how it was working to access what I needed to.

I will look at sessionStorage too to see if that will be of any use.

8

While this works its definitely not the Intention to directly modify the state. It can cause issues down the road as you’re modifying stuff outside the async queue and at least debugging with reduxDevtools or history support won’t work properly. So its certainly a better idea to trigger an action and setting the new radio value this way