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.

Sign up for GitHub

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

Jump to bottom

[Snyk] Upgrade redux-starter-kit from 0.4.3 to 0.9.1 #4

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

[Snyk] Upgrade redux-starter-kit from 0.4.3 to 0.9.1 #4

wants to merge 1 commit into from

Conversation

snyk-bot
Copy link

Snyk has created this PR to upgrade redux-starter-kit from 0.4.3 to 0.9.1.

ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.
  • The recommended version is 13 versions ahead of your current version.
  • The recommended version was released 9 months ago, on 2019-10-18.
Release notes
Package name: redux-starter-kit
  • 0.9.1 - 2019-10-18

    The switch to TSDX accidentally dropped the re-export of types like Action from Redux.

    Changelog

    • Fix broken re-export of Redux types d70dc31

    v0.9.0...v0.9.1

  • 0.9.0 - 2019-10-18

    This release contains only build tooling changes and package updates. We've switched our build setup from a homegrown Rollup config to use TSDX instead. We're also running CI tests against multiple versions of TypeScript to try to prevent any future type changes that might affect older versions.

    As part of the TSDX changes, the published package now contains the types in a single combined index.d.ts file instead of separate files, which may work better in certain build tooling setups.

    In the process, we've also updated Immer from 2.1.5 to 4.0.1. This primarily adds auto-freezing of all state objects in development, but shouldn't have any actual changes for your code. See the Immer release notes for more details.

    Barring any new issues, this will likely be the last point release before 1.0 release candidates in the next couple days.

    Changelog

    v0.8.1...v0.9.0

  • 0.9.0-alpha.1 - 2019-10-18

    0.9.0-alpha.1

  • 0.9.0-alpha.0 - 2019-10-17

    0.9.0-alpha.0

  • 0.8.1 - 2019-10-16

    This patch release fixes a couple small cross-version TypeScript issues that popped up in 0.8.0.

    Changelog

    v0.8.0...v0.8.1

  • 0.8.0 - 2019-10-15

    This release contains a couple breaking changes, including one that will affect almost all existing users. The plan is for these to be the final breaking changes before 1.0 is released, and that 1.0 will hopefully be out within the next couple weeks.

    Breaking Changes

    createSlice Now Requires a name Field

    So far, createSlice has accepted an optional field called slice, which is used as the prefix for action types generated by that slice:

    const counterSlice1 = createSlice({
    slice: "counter", // or could be left out entirely
    initialState: 0,
    reducers: {
        increment: state => state + 1,
    }
});

    The slice field has been changed to name, and is now required to be a non-empty string.

    const counterSlice1 = createSlice({
    name: "counter", // required!
    initialState: 0,
    reducers: {
        increment: state => state + 1,
    }
});

    This removes cases where multiple slices could have accidentally generated identical action types by leaving out the slice name while having similar reducer names. The field name change from slice to name was made to clarify what the field means.

    Migration: change all uses of slice to name, and add name to any createSlice() calls that didn't specify it already.

    createAction Defaults to a void Payload Type

    Previously, createAction("someType") would default to allowing a payload type of any when used with TypeScript. This has been changed to default to void instead. This means that you must specify the type of the payload, such as createAction<string>("someType").

    Note that this is not necessary when using createSlice, as it already infers the correct payload types based on your reducer functions.

    Migration: ensure that any calls to createAction() explicitly specify the payload type as a generic.

    Other Changes

    createSlice Exports the Case Reducer Functions

    createSlice already returned an object containing the generated slice reducer function and the generated action creators. It now also includes all of the provided case reducers in a field called caseReducers.

    const todosSlice = createSlice({
    name: "todos",
    initialState: [],
    reducers: {
        addTodo(state, action) {
            const {id, text} = action.payload;
            state.push({id, text});
        },
        toggleTodo(state, action) {
            const todo = state[action.payload.index];
            todo.completed = !todo.completed
        }
    },
    extraReducers: {
        ["app/logout"](state, action) {
            return []
        }
    }
});
console.log(todosSlice)
/*
{
    name: "todos",
    reducer: Function,
    actions: {
        addTodo: Function,
        toggleTodo: Function,
    },
    caseReducers: {
        addTodo: Function,
        toggleTodo: Function
    }
}
*/

    Notes

    Special thanks to @phryneas for coaching me through finally starting to get a vague grasp on some very complicated TS types :)

    Changelog

    v0.7.0...v0.8.0

  • 0.7.0 - 2019-09-08
    Read more
  • 0.6.3 - 2019-07-29

    One of the major limitations of RSK thus far is that the generated action creators only accept a single argument, which becomes the payload of the action. There's been no way to do things like:

    • add a field like meta, which is commonly used as part of the "Flux Standard Action" convention
    • pass in multiple function parameters to the action creator, and process them to set up the payload
    • Encapsulate setup work like generating unique IDs before returning the action object

    That also means that the code dispatching the action has been entirely responsible for determining the correct shape of the payload.

    This release adds the ability to pass in a "prepare" callback to createAction. The prepare callback must return an object containing a payload field, and may include a meta field as well. All arguments that were passed to the action creator will be passed into the prepare callback:

    const testAction = createAction(
    "TEST_ACTION",
    (a: string, b: string, c: string) => ({
        payload: a + b + c,
        meta: "d"
    })
)

    console.log(testAction("1", "2", "3"))
    
// {type: "TEST_ACTION", payload: "123", meta: "d"}

    createSlice has also been updated to enable customizing the auto-generated action creators as well. Instead of passing a reducer function directly as the value inside the reducers object, pass an object containing {reducer, prepare}:

    const counterSlice = createSlice({
	slice: 'counter',
	initialState: 0,
	reducers: {
	    setValue: {
		  reducer: (state, action: PayloadAction<number>) => {
		      return state + action.payload
		  },
		  prepare: (amount: number) => {
		      if(amount < 0) {
		          throw new Error("Must be a positive number!");
		      }
		      return {payload: amount}
		  }
	  }
	}
})

    This resolves the related issues of #146 and #148 .

    Changes

    v0.6.2...v0.6.3

  • 0.6.2 - 2019-07-22

    0.6.2

  • 0.6.1 - 2019-07-18
    Read more
  • 0.6.0 - 2019-07-16
  • 0.5.1 - 2019-04-30
  • 0.5.0 - 2019-04-28
  • 0.4.3 - 2019-01-27
from redux-starter-kit GitHub release notes
Commit messages
Package name: redux-starter-kit

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.

For more information:

🧐 View latest project report

🛠 Adjust upgrade PR settings

🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@snyk-bot