39 Matching Annotations
  1. Aug 2019
    1. I was so fed up of the mega amounts of boilerplate with Redux and the recommendation of keeping your data loading at view level. It seems to me that things like this, with components being responsible for their own data, is the way to go in the future.
  2. Apr 2019
  3. Jan 2019
    1. 这样可以方便的进行单元测试,不需要模拟Api.fetch函数的具体返回结果。

      非模拟时,由redux-saga内部的调度器帮我们执行 next(在异步函数或副作用函数执行获得结果后);

      模拟时,由测试函数自己根据需要执行 next,所以说无需模拟 Api.fetch 函数的具体返回结果,从而为测试带来了方便

  4. Nov 2018
  5. Oct 2018
  6. Sep 2018
  7. Jul 2018
    1. const shopItemsSelector = state => state.shop.items const taxPercentSelector = state => state.shop.taxPercent

      This is a selector

    2. const subtotalSelector = createSelector( shopItemsSelector, items => items.reduce((acc, item) => acc + item.value, 0) )

      This is a memoized selector. items.reduce will be evaluated during the first call. Any subsequent call with the same parameters will return the result without computing items.reduce.

  8. Apr 2017
  9. Feb 2017
  10. Apr 2016
    1. I’ve personally seen two big benefits after adopting this strict separation in production apps. The first is that teams can more easily reuse the Presentation Components because they are nothing more than html/css. Over time this will allow the team to amass a great component library that is more composable allowing even greater code sharing across the organization. The second benefit is that teams can more easily upgrade the infrastructure that powers data flow throughout the application. Because this code is isolated in the Container Components we don’t need to untangle the plumbing code from the html/css that displays it. So you want to swap your global store for an ember service? No problem! We just modify the entry point in the Container Components and the data still flows down to any Presentational Components like it did before the refactor.
  11. Mar 2016
    1. Therefore we've built https://github.com/salsita/redux-side-effects which is at least "somehow" trying to simulate the Continuations with Effect handlers approach. The idea is very simple, if reducer was generator then you could simply yield side effects and return mutated app state. So the only condition is to turn all your reducers into function* and use yield* whenever you want to compose them.

      This also looks like an interesting and potentially relatively simple take on supporting effects in reducers.

    2. Very interesting thread with a discussion on how to improve handling of effects in Redux and make Redux applications composable ala. the Elm Architecture.

      Redux Loop looks like a very interesting take on supporting the Elm arch with the current version of Redux

    1. This is a useful introduction through recent developments in client-side data management and an overview of the different choices available when building a new application and guidance on what is appropriate for different sizes of app.

  12. Feb 2016
  13. Jan 2016
    1. All kinds of frameworks and architectures have state. In Ember apps and Backbone apps, state is in Models. In Angular apps, state is often in Factories and Services. In most Flux implementations, it is in Stores. How does Redux differ from these?

      Useful explanation of how state storage in Redux differs from other frameworks.

    2. Useful tutorial that covers combined usage on the client and server.

    1. You can call store.dispatch(action) from anywhere in your app, including components and XHR callbacks, or even at scheduled intervals.

      For an example of dispatch at regular intervals, the SoundRedux media player app dispatches an action every time the play time of the current song, measured in seconds, changes.

    2. Now todoApp just gives it the slice of the state to manage, and todos knows how to update just that slice.

      This is great for the simple case where there is no interdependent state. For ideas on what to do when one part of the state tree depends on another, see http://stackoverflow.com/questions/34782948/how-can-i-model-interdependent-data-with-cascading-updates-in-redux/34796163#34796163

  14. Dec 2015
  15. Sep 2015
    1. If your head boiled from reading the above section, imagine what it was like to write it.

      I find this slightly disturbing to read in the documentation (!)

  16. Aug 2015
    1. Probably the best explanation I've seen yet on the why and how of a functional approach to UI state management with Redux