UPD: it's now a part of the ES2018

It might be slightly improved via anon-standardised yet properties spread syntax:

return {    ...state,    notificationBar: {        ...state.notificationBar,        open: true,    },};

Although it's possible to use the spread operator, there are lots of other ways to achieve the same result without even needing a future JS compiler for a non standardised feature. Here are some other options in no particular order.

Return a Literal

If you are sure that your state won't grow, then you can simply return the entire new state as a literal.

return {  notificationBar: {    open: true  }}

However, that's not often going to be appropriate because it's unlikely that your state will be this simple.

Combine Reducers

Redux gives you a utility method for combining several reducers that work on different parts of the state object. In this case, you'd create anotificationBar reducer that handled this object alone.

 createStore(combineReducers({   notificationBar: function(state=initialNBarState, action) {     switch (action.type) {       case actions.LAYOUT_NOTIFICATIONBAR_OPEN:         return Object.assign({}, state, { open: true });   } });

This prevents you from having to worry about the top level of properties, so that you can avoid nesting calls toObject.assign.

If your state can logically broken down into clearly defined sections then this is probably the most idiomatic way to solve this problem.

Use Immutable Data

You can use an persistent data structures library to create data structures than can be modified to return a copy.

Mori

Mori is the result of compiling Clojure's data structures and functional API into JS.

import { hashMap, updateIn } from 'mori';const initialState = hashMap(  "notificationBar", hashMap(    "open", false  ));// ...return updateIn(state, ['notificationBar', 'open'], true);

ImmutableJS

ImmutableJS is a more imperative approach to bringing the semantics of Hash Array Mapped Tries from Clojure's persistent data structures to Javascript.

import { Map } from 'immutable';const initialState = Map({  notificationBar: Map({    open: true  });});// ...return state.setIn(['notificationBar', 'open'], true);

AliasObject.assign

You can create a friendlier version ofObject.assign to write terser versions of the code above. In fact, it can be nearly as terse as the... operator.

function $set(...objects) {  return Object.assign({}, ...objects);}return $set(state, {  notificationBar: $set(state.notificationBar, {    open: true,  })});

Use Immutable Helpers

There are a number of libraries that also offer immutability helpers for making modifications to regular mutable objects.

react-addons-update

React has had a built in set of immutability helpers for a long time. They use a similar syntax to MongoDB queries.

import update from 'react-addons-update';return update(state, {  notificationBar: {    open: { $set: true }  }});

dot-prop-immutable

This library allows you to use familiar dot paths to specify updates to (nested) properties.

import dotProp from 'dot-prop-immutable';return dotProp.set(state, 'notificationBar.open', true);

update-in

This library is a wrapper aroundreact-addons-update and provides a more functional syntax for updating (nested) properties.

Rather than passing a new value, you pass a function which takes the old value and returns a new one.

import updateIn from 'update-in';return updateIn(state, ['notificationBar', 'open'], () => true);

immutable-path

For updating properties, this library is like a cross betweendot-prop-immutable andupdate-in.

import path from 'immutable-path';return path.map(state, 'notificationBar.open', () => true);

You can use Lenses.

import { set, makeLenses } from '@DrBoolean/lenses'const L = makeLenses(['notificationBar', 'open']);const notificationBarOpen = compose(L.notificationBar, L.open)const setNotificationBarOpenTrue = set(notificationBarOpen, true)const a = { notificationBar: { open: false } }const b = setNotificationBarOpenTrue(a) // `a` is left unchanged and `b` is `{ notificationBar: { open: true } }`

You can think about Lenses as compositional property access/update.

Some good resources about Lenses:

• videoLenses Quick n' Dirty
• practical articleLenses and Virtual DOM Support Open Closed
• videoFunctional programming patterns for the non-mathematician
• article about combiningLenses with imutable.js

If you are ok with readinglisps, I would also recommend taking look at this excellentintroduction to lenses fromracket docs. Finally, if you want to go deeper and are ok with readinghaskell you can watch:Lenses - compositional data access and manipulation.

If you're usingImmutable.js, you can look underNested Structures topic some functions that may help you, I personally usemergeDeep:

prevState.mergeDeep({ userInfo: {  username: action.payload.username,} }),

In addition to what've been said earlier, here is a functional way withRamda:

import { assocPath } from 'ramda';const o1 = { a: { b: { c: 1 }, bb: { cc: 22 } } };const o2 = assocPath(['a', 'b', 'c'])(42)(o1);console.log(o1 !== o2, o1.a !== o2.a); // new copies of "changed" objectsconsole.log(o1.a.bb === o2.a.bb); // deep unchanged properties are copied by reference

All advice here are great and valid, but I would like to offer another solution. The problem which appears here is definitely a common pattern, so I think it is much better just to write your own interface for such updates and stick with it inside reducers, and use one function to update deeply inside all your reducers.

For example,I have created a library, where I tried to address this issue the next way: I get the type of the module (so-called "tile"), function to perform operations (both async and sync) and desired nesting based on passed params. So, for your case it will be something like:

import { createSyncTile } from 'redux-tiles';const uiTile = createSyncTile({  type: ['ui', 'elements'],  fn: ({ params }) => params,  // type will be `notificationBar`  nesting: ({ type }) => [type],});

And that's it -- it will be update correctly on arbitrary nesting. Also, tile provides selectors, so you don't have to worry personally where precisely data is located, you can just use them.So, I don't want to say it is the best solution, but the idea is pretty simple -- don't be afraid to write your own implementation, and then just use factory to solve this issue.

• javascript
• reactjs
• redux