initial work on create slice

[neurosnap]

Extracted from this comment: #17 (comment)

#17

[nickmccurdy]

Thanks for the contribution.

This looks similar to createReducer but I like how the actions are included in the results. Do you think we could include this in the existing createReducer API or do you want it to be seperate?

As far as TypeScript support goes, I have State inference working in #12. I can't get Actions working yet but I'd appreciate a review if you have time.

[neurosnap]

I updated the PR with the requested changes. I also added some tests. Happy to make more changes as recommended.

[nickmccurdy]

Thanks. So the goal compared to createReducer is to bundle in actions instead of just returning a merged slice reducers, right? Do you think we could make the API more like createReducer with initialState, actionsMap, and slice as ordered args? Also, why is the slice property in the returned bundled?

[neurosnap]

So to clarify you would like to see:

const counter = createSlice({
  initialState,
  actionsMap,
  slice,
});

I added slice as a way to get the slice back as a const if a string literal was used inside the createSlice function. I can remove that.

[nickmccurdy]

Ah, so it's just for namespacing actions? That sounds like it could still be useful, and I do like that API signature more now.

@markerikson What do you think about this API for wrapping createReducer in reducer and action bundles with optional slice based namespacing?

[markerikson]

Uh... yes, that was exactly the point in the first place :) Like autodux, but using our own createReducer internally.

[nickmccurdy]

Cool, I'm in favor of merging as long as we can get the order in #37 (comment)

[markerikson]

I think I'd prefer a single "options object" rather than multiple positional arguments for this API, but it's up for discussion.

[nickmccurdy]

createReducer already has a signature of (initialState, actionsMap), so I'd prefer to stay consistent by either following the order in #37 (comment) or also converting createReducer to an options object signature.

Is there a use case where it would make sense for the user to not pass actions as an object? I noticed that it's optional for createSlice but not createReducer, which seems inconsistent to me. Can you remove = {}?

[neurosnap]

options object makes sense to me personally, but I don't care either way.

This library also has nothing to do with creating selectors like autodux does, so it is not at perfect parity. I personally think that auto-generating selectors will really bloat this code and beyond a root selector for each slice I wouldn't add anything more than that.

[neurosnap]

Also, it might be useful to write a little helper for creating actions that anyone can use. Example:

export default function createAction(type) {
  const action = (payload) => ({
    type,
    payload,
  });

  action.toString = () => `${type}`;
  return action;
}

// usage
const increment = createAction('INCREMENT');
console.log(increment);
// -> 'INCREMENT'

This will allow us to stringify the action returned from createSlice and is something very similar to what autodux does. This will allows createSlice to work with libraries like redux-saga

[markerikson]

I'd actually like to clone the "create selectors automatically" functionality if we could.

[neurosnap]

Ok, if it's alright with you I would prefer to add that in as a separate PR. It seems distinct enough to be its own feature.

[markerikson]

Superseded by the work done on robodux and ported directly to redux-starter-kit, as discussed in #17 . @neurosnap , thanks for writing robodux and allowing us to port that over!