Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upinitial work on create slice #37
Conversation
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
I updated the PR with the requested changes. I also added some tests. Happy to make more changes as recommended. |
This comment has been minimized.
This comment has been minimized.
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? |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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? |
This comment has been minimized.
This comment has been minimized.
Uh... yes, that was exactly the point in the first place :) Like |
This comment has been minimized.
This comment has been minimized.
Cool, I'm in favor of merging as long as we can get the order in #37 (comment) |
This comment has been minimized.
This comment has been minimized.
I think I'd prefer a single "options object" rather than multiple positional arguments for this API, but it's up for discussion. |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
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 |
This comment has been minimized.
This comment has been minimized.
I'd actually like to clone the "create selectors automatically" functionality if we could. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
Superseded by the work done on |
neurosnap commentedAug 22, 2018
Extracted from this comment: #17 (comment)
#17