Are there any approaches when using both immutable.js and redux-form that don't require calling .toJS()?
I can see the suggested approach on this issue is to call .toJS() on the Map object before passing it to the form:
getFormState: (state, reduxMountPoint) => state.get(reduxMountPoint).toJS()
Does this not compromise the performance benefit you get from using immutable.js and limit memoization?
I'm interested to know the performance impact of this, will it still be worth using immutable.js in a form heavy application? Are there any other approaches that don't rely on .toJS()?
As I contemplate the future of redux-form, I have been going back and forth on whether or not to use ImmutableJS internally. I briefly entertained the idea that I could somehow get the same codebase to work using both, via some facade, but, in the end, the interfaces are just too different, the ImmutableJS interface being considerably more verbose, as a consequence of not enjoying native language syntax.
Making an alternate version of redux-form that uses ImmutableJS would require changing almost every line of code and would be a maintenance nightmare.
Unless someone can show me that the performance advantages of using ImmutableJS outweigh the cost of giving the .toJS() burden to the people (majority?) who choose not to use ImmutableJS, I think the better course of action is to, like Redux itself, remain un-opinionated about storage libraries.
Are there any other approaches that don't rely on
.toJS()?
So, to answer your question: No, if a library managing your Redux reducers is expecting plain javascript objects, and you are using ImmutableJS for your Redux store, you've got to do the conversion yourself.
Wish there were a better answer...
EDIT: Version 6 of Redux Form supports ImmutableJS out of the box.