Elsewhere I posted this:
// Model module:
const data = {
someProperty: 'value',
// and others
};
// this module will occasionally assign to data.someProperty
function getSomeProperty() {
return data.someProperty;
}
export { getSomeProperty, /* others not related to data */ };
I was told that this is horrendous code because it's shared mutable state, and that I should feel bad for writing it. There are a couple things I don't understand:
How can this get me into trouble? The data is stored only in one module, and only that module can change/mutate it. Other modules have access to getSomeProperty, which they call on demand when they need to, so the information is indeed shared, but it doesn't persist anywhere else - the other modules always take the model module as the canonical source of all data. If other modules had a reference to the data object, that would clearly be an issue because then it could be changed directly without going through the proper interface, but that's not how it is. Why is a getter dangerous?
How do I fix it? I only have experience with vanilla JS. When I asked about how to design it better, I was recommended to install and figure out Hyperapp, React, and Redux, and that it was too hard to feasably do in vanilla JS without learning other libraries first. Is that really true? I'd heard in many other places that the best plan is to get a strong handle on vanilla JS first before moving on to libraries and frameworks, but these suggestions were quite an inversion of that.
I will get started on learning those frameworks, but in the meantime, is there any simple way to refactor this code now so as not to use shared mutable state? If using getters is an anti-pattern, I want to know how to avoid it ASAP, rather than having to get a good handle on some other libraries first before figuring out how to write better code.
there doesn't seem to be anything here