redux: Redux 4 breaking changes

Hating a product is not very a productive place for making technical decisions. 😉 Let’s keep this thread focused and not deviate on this anymore.

Oh man I wish you have said, “we don’t support IE” instead of mentioning the version.

OK, merging next into master. 4.0.0-beta.1 will be available soon™!

Folks, we only said we’re dropping support for IE8. No other version. If you need support for that version, you can continue to use 3.x. We won’t be unpublishing that version on release of 4.0 and it will continue to work just fine, as it does right now.

You don’t have to upgrade to every new release immediately. It’s OK to run slightly out of date versions of stuff. Want to know how I know? This very website, GitHub, is running on a version of Rails that is about 5 years old at this point. And that’s OK.

We can also migrate typings to TypeScript 2.1, introduce null-safety and strict mapped types for combineReducers.

IE still has a large marketshare, especially in US corporate environment. No major general-purpose JS package is going to drop support for it completely. This isn’t being considered for Redux and is off-topic.

Because the only reason they are still used, is that everyone keeps supporting them. Users of internet explorer is not gonna stop using computers if suddenly internet explorer stops working. It is a waste of time to give a moment of thought to how things would work in IE. I don’t understand why it was worth a thumbsdown.

@guijesuis

Awesome that you discovered this pattern while working on a real world app. I agree with you that this seems like a great idea. In fact this is exactly what https://github.com/yelouafi/redux-saga offers.

I’m removing the enhancer overhaul from this, since that’s pretty broad and hasn’t been really moved forward beyond the proof-of-concept phase. It shouldn’t be a blocker for getting some other breaking changes pushed out. We can include it in a later major.

I’d like to push forward on getting this together. The TS folks are probably tired of yelling at me about when the next branch is going to land in master 😃 But also, we shouldn’t be afraid to make breaking changes in more incremental moves. Nothing too drastic has shown up on next so far, so it’s a good way to clean things up and avoid technical debt. If folks can’t afford a change, we can support the 3.x versions indefinitely, just like we do on React Router.

I d like to share a little bit of my experience with redux. i spent 5 month working on a fairly large redux application. Redux did an awesome job. Nevertheless after few weeks of dev we hit the issue “how to deal with asynchronous actions”. At first we used redux thunk and it did the job, but ours actions grew rapidly in complexity. At that point i decided to create a middleware base and generator functions (similar to redux saga but it was still actions). it allowed us to write complex action like the following login action

export function* login(login, password) {
  var {state} = yield {
    type: types.ON_DO_NOTHING
  };

  if (state.cursor == "wait")
    return {type: types.ON_DO_NOTHING};

  yield {type: types.ON_WAITCURSOR_START};

  var {state,result} = yield RestManager.Call({
    method: REST.METHODS.POST,
    url: REST.RESOURCES.SESSIONS,
    header: RestManager.getAuthenticationHeader(login, password)
  });

  if (result.status == "success") {

    yield  {
      type: types.ON_REQUEST_SESSION_ID_COMPLETED,
      sessionID: result.data.content.sessionId,
    };

    var {state,result} = yield RestManager.Call({
      method: REST.METHODS.GET,
      url: REST.RESOURCES.FEATURES + "/AIPLM_INTEGRATION/users/" + login,
      header: RestManager.getBasicHeader(REST.APPLICATION_TYPE.JSON)
    });

    if (result.status == "success") {

      yield {type: types.ON_GET_CURRENT_DOCUMENT};
    }
    else {

      yield {type: types.ON_DISCONNECT_YES};

      yield messagesAction.displayMessage("error", i18n.t("NO_FEATURE_MESSAGE"));
    }
  }
  else {

    yield messagesAction.displayMessage("error", result.data.content);
  }

  return {type: types.ON_WAITCURSOR_STOP};
}

And that how we resolved our issue with asynchronous action…

I now believe that redux is mixing 2 distinct concept as one, action and store effect. • Actions should be what the user or computer trigger (ex: click on button, clock-tic , post form …) • Store effects should be triggered by action to mutate the store

Thanks @hmillison! Just need to figure out #2599 and I think we have something ready for alpha! 🥇

BTW, I think imports of the form ${package}/lib/${module} are not ideal, though they’re the easiest way to go. Especially if you have a separate ES module build for which tree shaking works anyway, you should probably expose those as ${package}/${module} imports, potentially by npm publishing a subdirectory rather than the project’s Git root.

I’ve updated the next branch to not be over 10 months out of date 😉 There are only 4 commits on there, so it should be a much more manageable starting point now.

https://github.com/reactjs/redux/compare/master...next

Why?

The most extreme option that would still be reasonable would be dropping support for IE < 11. All modern JS features (but Proxy and new.target) can be polyfilled in it.

IE8, OTOH, is a risk because of how easy it is to crash when using Object static methods… which happens all the time in transpiled classes and modules.

we now support importing redux/lib/*

We do? I always viewed any import from outside of main (basically any import with a slash) as accessing private APIs. Your main should be the list of public APIs provided by the library. The only exception is for reducing your bundle size (until ES6 module builders become more readily available), but you would be doing this as an optimization step after importing something from the public API.

Drop support for IE8.

Then we can import #1123 finally? 😄