Roadmap - v9

[renatoagds]

We'll start to create the roadmap for next major release of ReduxForm.

Based on that I want to ask help for the community to create this roadmap.

Please, help us and put here your ideas.

---

Current tasks for v9:

• Bump for Redux v7 Upgrade dev dependency to react-redux v7 #4431
• Move docs for Docusaurus.
• Rewrite core and extract to new package to improve readability and maintainability.
• Support render props
• Remove deprecated configs.
• Support more frameworks than React.
• Add hooks support
• Remove Field, Fields, FieldArray Instance API because of bad practice
• Drop immutable.js support.
• Move examples to another repo

Wild tasks

• Migrate codebase to TypeScript, keep flow types.
• Allow to detach from redux, allowing useReducer like api
• Add a global redux-form provider, that will allow to pass some global options, (e.g. plain or immutable structure, getState)

As soon we get more ideas, the current tasks will be update.

[zazapeta]

Hi there, (sorry for my bad english, I'm trying hard to do my best on it)

I have two 'questions/suggestions' :
A. I'm used to follow the https://semver.org/ for bumping versions, and genuinely like it.
In a nutshell, semver is :
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
As I can see, Redux-Form is not following it (always backward compatible except for the v5-v6).
Am I wrong ? If not, what do you think to embrace it with the v9 ?

B. Keeping the same API, and everything the same, but re-write redux-form by using react-final-form behind to merge the efforts on both projects ?

Cheers 🍻 - zazapeta

[renatoagds]

@zazapeta I wasn't following redux-form close to check that, but what examples do you have about not following semver? Anyway, is the plan to follow it from now.

About rewrite redux-form, that's not the plan, basic because redux-form codebase is too large, has differences between react-final-form (like immutable) and for me, doesn't make sense to keep a library written in top of another, which benefits we could have instead of improving react-final-form? This kind of movement is too dangerous and doesn't match with the future plans for redux-form.

[zazapeta]

Hi @renatoagds,
Thanks you for your answers.

This kind of movement is too dangerous...

I can't agree much more !

which benefits we could have instead of improving react-final-form ?

I do not have any answers....... >_>
Shamefully, I'm feeling a little bit stupid now....... 😳😳😳 🙈

Advice for me: Next time, think twice before posting

Anyway,
Thanks you again (and sorry wasting your time) !

🍻 - zazapeta

[venondev]

Maybe just a small thing, but it would be great if the action creators could be exported in seperate files as the rest of redux form, so you can only require the actions you need.

https://redux-form.com/6.7.0/docs/faq/bundlesize.md/

[Asday]

Honestly the most important to me is just drawing a line under all the showstopping bugs, and secondarily getting up to date with react and redux.

Personally, being out of date doesn't affect me, as I'm on Expo, and restricted to a land without hooks, but that's (hopefully) a short term thing.

Any new features can for sure wait as far as I'm concerned.

[renatoagds]

@Asday Agreed that we should fix bugs and get a stable v8. But that can't stop us thinking in the future and that's the point that I want to focus in this issue. IMO we could parallelise both works.

[matoilic]

Two things I missed a lot in some projects were:

• The ability to set errors explicitly on a field or on the form via a redux action, without having to take the way over stopSubmit. There I always need to take extra steps to not lose the existing errors on other fields than the one I want to update.
• The ability to trigger the revalidation of a field or the whole form from outside. I often have the case, that when the user changes a value in one field it might invalidate an other field's value.

Also, using ES6 modules in ReduxForm by default would be really nice. Currently, if you want to optimize the bundle size you need to import from individual files. It would be really nice if the package's "main" file would already use ES modules.

[Asday]

I'm fairly sure your second case is already what happens - synchronous validation happens on every onChange event.

[renatoagds]

@matoilic Could describe which cases do you need to import from individual cases? Just to have a proper scenario for this feature.

[iamandrewluca]

https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines
https://github.com/semantic-release/semantic-release

[iamandrewluca]

Move https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/redux-form in this repo, fix them and keep up to date with every change

[iamandrewluca]

One more ambitious idea. Maybe extract all redux logic, and have to packages redux-form, redux-form-react, or even redux-form-angular ))

or

• @redux-form/reducer
• @redux-form/react
• @redux-form/angular

[renatoagds]

@iamandrewluca Can you explain more what's your idea with commit guidelines links? About extract redux logic, looks like a good idea. It could be combine with the core rewrite.

[iamandrewluca]

commit guidelines links

Writing commits and keeping a format like angular does makes easier to generate CHANGELOG from commits, also version number increasing, and publishing made easier.

https://www.youtube.com/watch?v=ZXyx_1kN1L8

[iamandrewluca]

Also maybe we can move to react hooks underneath main components.

[iamandrewluca]

Last night I had an ideea. When rewriting core, a feature could be to decouple at user preference from redux, and just use react/useContext/useReducer.
That would be an option for reduxForm HOC and will save state in react instead of redux.

[matoilic]

A lot of good suggestions to improve redux-form. But I would suggest focussing on proper react-redux v7 compatibility and removing the usage of deprecated React APIs. Before starting to build new functionality, it might be useful to lay a clean and stable base with v9 and postpone the rest to v10.

For me, redux-form is currently the main blocker why I can't upgrade to react-redux v7 in projects which use it. And probably there are a lot of other devs out there in the same situation. Or did I understand #4431 wrong and redux-form is already compatible with react-redux v7?

[kangax]

@matoilic it's not compatible, we're blocked with redux update on that same issue

[iamandrewluca]

We are using in production this versions, and didn't encountered any issues yet.

{
  "react-redux": "^7.1.0",
  "redux": "^4.0.4",
  "redux-form": "^8.2.4"
}

[iamandrewluca]

@renatoagds current tasks are strictly for v9? Or some of them can be implemented even in v8, if will not be breaking changes?

[iamandrewluca]

Also maybe create a public chat (slack, discord, gitter...) for redux-form? Don't know any existing one.

[renatoagds]

@iamandrewluca

current tasks are strictly for v9? Or some of them can be implemented even in v8, if will not be breaking changes?

is not strict for v9, which one to you think is possible without breaking changes?

Also maybe create a public chat (slack, discord, gitter...) for redux-form? Don't know any existing one.

It's already a gitter channel, if you search there you'll find

[iamandrewluca]

Deprecate/remove Field/Fields/FieldArray Instance API because of bad practice
using a ref on Field/Fields/FieldArray should be passed down straight to passed component

[iamandrewluca]

Move examples to another repo

[renatoagds]

Closing this issue, since we'll enter RF in maintenance mode and avoid big changes in the current codebase.