State Setters boilerplate: suggestions, counter-arguments?

I find that I am creating a lot of boilerplate setters for each StoreState object.

E.g.

const JobStore = {
    jobData: {},
    jobBoard: [],
    jobList: [],
    setJobData: action((state, payload) => {
        const json = JSON.stringify(payload, ' ', 4)
        state.jobData = json
    }),
    setJobBoard: action((state, payload) => {
        state.jobBoard = payload
    }),
    setJobList: action((state, payload) => {
        state.jobList = payload
    }),

I have to do this because my thunks cannot directly set the state (which I understand the reason for that).

But it is a common feature in OO Programming to be able to automate the creation of property accessors (get/setters) for Object properties.

The userStoreState() makes the getters trivial for store properties. What about some sort of shorthand we can use in a thunk for property setters (a helper function?). I am only talking about items in the same store slice, (eg. setState() and not setStoreState() - but you could have that for folks that want to live dangerously).

[DrYSG]

One can also make this a bit more robust by using the immer {original} function:

    set: action((state, payload) => {
        const base = Object.keys(original(state))
        Object.entries(payload).forEach(([key, value]) => {
            if (base.includes(key)) 
                state[key] = value
        })
    }),
``

[ctrlplusb]

@DrYSG - I am going to shy away from introducing additional abstractions as being described above. My gut feeling is that this should belong in user-land. It is fairly easy to introduce your own helpers/abstractions in order to achieve what you feel is necessary on a per case basis.

Thanks for going through this in detail though. Perhaps others can learn from your journey if they visit this issue. 👍