If I commit an object like this to the store, render is being called multiple times
{
someProp: 123
otherProp: ABC
someArray: [{val:val,val:vcal}]
}

Is that by design or have I messed something up?

Hey there!

I belong to an open source security research community, and a member (@neopixel92) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

First thank you so much for this article and code. Such a nice break from untangling all the yarn and ts and other toolchain confusion.

I am still learning a lot of this stuff and I am trying to adapt this code for use with my app that is using LitElement.

Your sample code uses a new base class called component, and I was wondering what you would advise? Should I create myNewBaseClass that extends LitElements and include your constructor code? or is there a better approach? Thanks for any pointers

Thanks for this article, very informative and inspiring.

Could you explain the apparent redundancy between the mutation functions and the store's commit function?

For example, the addItem mutation is defined as:

addItem(state, payload) {
  state.items.push(payload); // store's state is updated after this runs

  return state;
}

This updates the store's state but the commit method then updates the state again:

commit(mutationKey, payload) {
  let self = this;

  if (typeof self.mutations[mutationKey] !== "function") {
    console.log(`Mutation "${mutationKey}" doesn't exist`);
    return false;
  }

  self.status = "mutation";

  let newState = self.mutations[mutationKey](self.state, payload); // state is updated after this runs 

  self.state = Object.assign(self.state, newState); // this update appears to be redundant as self.state already reflects newState

  return true;
}

One reason I can think for this is that a particular "mutation" might only return a new state object rather than manipulating the object it was passed e.g.

addItem(state, payload) {
  return { ...state, items: [...state.items, payload] }; // store's state is not changed by this so the update in the commit method is required
}

but the definition of a mutation in the article clearly states that mutations should update state ("mutations should always be simple because they have one job: mutate the store’s state"), so I'm not sure there's a need to code for this case.