-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
initial work on create slice #37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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. |
I updated the PR with the requested changes. I also added some tests. Happy to make more changes as recommended. |
69c1c8e
to
d65dedb
Compare
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? |
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 |
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? |
Uh... yes, that was exactly the point in the first place :) Like |
Cool, I'm in favor of merging as long as we can get the order in #37 (comment) |
I think I'd prefer a single "options object" rather than multiple positional arguments for this API, but it's up for discussion. |
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 |
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. |
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 |
I'd actually like to clone the "create selectors automatically" functionality if we could. |
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. |
Superseded by the work done on |
Extracted from this comment: #17 (comment)
#17