Skip to content
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

Create slice changes #197

Merged
merged 1 commit into from
Sep 23, 2019

Conversation

phryneas
Copy link
Member

These are the changes you requested over in #82

@netlify
Copy link

netlify bot commented Sep 22, 2019

Deploy preview for redux-starter-kit-docs ready!

Built with commit c58aa2c

https://deploy-preview-197--redux-starter-kit-docs.netlify.com

@phryneas phryneas changed the base branch from master to v0.8-integration September 22, 2019 12:24
@markerikson
Copy link
Collaborator

Great, thanks!

Ironically, I'm actually having second thoughts about the "return the reducer" thing:

https://twitter.com/acemarke/status/1175881949514219521

It's an interesting idea, and yet at the same time I'm not sure it buys much actual improvement.

Thoughts?

@phryneas
Copy link
Member Author

It's definitely nicer to use (took my a while to figure out that I could not use the slice directly in combineReducers), but the console.log in chrome is really bad :/
(Firefox works though: https://imgur.com/mIipct5 )

What about turning the idea around? Export a modified combineReducers from RSK that takes either functions or slices?

@markerikson
Copy link
Collaborator

No, one of the main points of RSK is that it's "just Redux". I don't want to have a special version of combineReducers.

Y'know, I think I've talked myself out of returning the reducer directly. Returning the object gives us a bit more flexibility in case we ever do add something else to createSlice, and I don't think there's all that much benefit in returning the reducer by itself. Let's drop that and just do the slice? -> name change.

Sorry for the whiplash :)

@markerikson
Copy link
Collaborator

markerikson commented Sep 23, 2019

@phryneas : just re-read your comment in the 1.0 thread.

Yeah, sure, let's go ahead and include the individual reducers in the slice object (which is also another argument for keeping it as an object). Main question is what to call it? Maybe caseReducers?

Semi-recapping:

const sliceObj = createSlice({
    name: "todos",
    initialState,
    reducers: {
        addTodo() {},
        toggleTodo() {}
    }
});

console.log(sliceObj);
/*
{
    actions: {addTodo, toggleTodo},
    reducer : fn(),
    caseReducers: {addTodo, toggleTodo}
}
*/

@phryneas
Copy link
Member Author

@markerikson okay. I'll revert the "reducer function" commit so that this can get merged and open a separate PR for the caseReducers (I think that name is fine) in the coming days.

@markerikson
Copy link
Collaborator

markerikson commented Sep 23, 2019

One additional request: can we throw an error if name is falsy? That would force the user to add a non-empty name.

DOH! I should actually read the code, shouldn't I :)

@markerikson
Copy link
Collaborator

Awright, looks good to me!

@markerikson markerikson merged commit a685bce into reduxjs:v0.8-integration Sep 23, 2019
markerikson added a commit that referenced this pull request Oct 15, 2019
* Create slice changes (#197)

* Include case reducers in createSlice result (#209)

* Fix missing name field in type test

* Include provided case reducers in createSlice output

- Added `caseReducers` field to the createSlice return object
- Added test and type test for returned case reducer
- Removed "Enhanced" terminology from types, and replaced with
  "CaseReducerWithPrepare" and "CaseReducerDefinition"
- Restructured logic to only loop over reducer names once, and
  check case reducer definition type once per entry

* Add type tests for correct case reducer export inference

* Rewrite caseReducers types for correct inference of state + action

* Add type test for reducers with prepare callback

* Fix type inference for actions from reducers w/ prepare callbacks

* Clean up type names and usages

* Use a generic State type in ActionForReducer

* Re-switch Slice generics order

* Use `void` instead of `any` for undefined payloads (#174)

* Change default createAction payload type to void to make it required

* Fix createAction type tests per review

* Update tutorials for v0.8 (#213)

* Update basic tutorial with createSlice changes

* Update intermediate tutorial with createSlice changes

* Update advanced tutorial with createSlice changes

* Change existing commit links to point to reduxjs org repos
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants