4.0 Roadmap

[fzaninotto]

We're starting to think about the next major milestone for react-admin. It'll mostly be a cleanup release, removing all the deprecated features and the compatibility layers we put in place. It should also be the occasion to use the latest major version of our dependencies.

Breaking Changes

• ✅ Upgrade material-ui to v5 ([BC Break] Upgrade to MUI v5 #6650)
• ✅ Remove redux-saga and saga-based side effects ([BC Break] Remove Redux-saga #6684)
• ✅ Remove declarative side effects support in dataProvider ([BC Break] Remove declarative side effects in dataProvider #6687)
• ✅ Remove connected-react-router (Remove connected-react-router #6704)
• ✅ Remove support for undoable prop now that we have mutationMode (Remove undoable #6711)
• ✅ Replace react-final-form with formik or react-hook-form ([BC Break] React Hook Form #7087)
• ✅ Upgrade react-router to V6 (Migrate to React router v6 #6873)
• ✅ Remove permissions injection in main route controllers (Remove permissions prop injection from main views #6921)
• ✅ Switch WithPermissions wrapping to a useAuthenticated hook in main controllers (based on a boolean so that users can create an anonymous show view with <Show authenticated={false}>) (Remove permissions prop injection from main views #6921)
• ✅ Replace Redux-based query cache by react-query and initial data from query cache
  • ✅ useGetOne ([BC Break] Introduce react-query in useGetOne #6779)
  • ✅ useGetList ([BC Break] Migrate useGetList to react-query #6916)
  • ✅useGetMany ([BC Break] Migrate useGetMany to react-query #7006)
  • ✅useGetManyReference ([BC Break] Migrate useGetManyReference to react-query #7016)
  • ✅useCreate ([BC Break] Migrate useCreate to react-query #7025)
  • ✅ useUpdate (Update useUpdate to use react-query #6891)
  • ✅useDelete ([BC Break] Migrate useDelete and useDeleteMany to react query #7035)
  • ✅useUpdateMany ([BC Break] Update useUpdateMany to use react-query #7020)
  • ✅useDeleteMany ([BC Break] Migrate useDelete and useDeleteMany to react query #7035)
  • ✅ Cleanup data reducers ([BC Break] Cleanup dataProvider code #7001)
• ✅ Use MUI autocomplete instead of our own (Introduce a new AutocompleteInput based on MUI Autocomplete #6924, Migrate AutocompleteArrayInput to MUI Autocomplete #6971)
• ✅ Remove Resource initialization, Store Resource definitions in Context rather than in store ([BC Break] Remove Resource initialization  #7051)
• ✅ Remove deprecated sort prop in <DataGridHeaderCell> ([BC Break] Change setSort signature to make it consistent acrosse components #7065)
• ✅ Rename currentSort to sort ([BC Break] rename currentSort to sort #7076)
• ✅ Change the Record TypeScript name (which already exists in TypeScript) ([BC Break] Rename Record type to RaRecord #7078)
• ✅ Put Notification component in the AdminUI to avoid gotchas when overriding the layout, and remove notifications from Redux store ([BC Break] Use context to store notifications instead of Redux #7082)
• ✅ Remove basePath ([BC Break] Add support mounting admin inside a sub path #7100)
• ✅ Allow to pass custom params to each dataProvider hooks (Add support for meta parameter in queries #7116)
• ✅ Add support for partial pagination (i.e. no total) (Partial pagination #7120)
• ✅ Remove TestContext (AdminContext does the trick) and ra-test ([BC Break] Remove ra-test #7148)
• ✅ Add ChoicesContextProvider in all ReferenceInputs to avoid child cloning with choices and allow choices filtering, pagination, and sorting (Introduce ChoicesContext #7185)
• ✅ Replace RichTextInput with TipTap version ( Replace Quill RichTextInput With TipTap RichTextInput #7153)
• ✅ Remove prop injection and child cloning, use context instead ([BC Break] Add ReferenceOneField #7060, Avoid cloning in Title #7218, Avoid cloning element for optionText #7215, Avoid cloning elements in AppBar #7214, Avoid cloning elements in ArrayField and ReferenceManyField views #7207, Avoid cloning elements in Create and Edit views #7206, Avoid cloning elements buttons #7205, Avoid cloning elements in Authenticated #7203)
• ✅ Avoid cloning inputs to pass variant and margin, and document theme override instead (Avoid cloning elements in forms #7223)
• ✅ Remove HOCs (like addField) and render props
• ✅ Make the signatures of useGetList, useGetMatching, useGetMany and useGetManyReference consistent (some return a RecordMap, some return an array of records)
• ✅ Upgrade dependencies to their latest major versions
• ✅ Remove useGetMatching (use getList instead) ([BC Break] Migrate useGetList to react-query #6916)
• ✅ Add support for sx props in all ra-ui-materialui components
• ✅ Store user preferences outside of Redux (and make them persistent) ([BC Break] Replace Redux by custom store #7158)
• ✅ Backport Preferences features from ra-enterprise
• ✅ Remove Redux ([BC Break] Retire redux #7177)
• ✅ Review UI and alignments
• ✅ Profile and optimize
• ✅ check FIXMEs in code
• ✅ Review all examples to make sure the code is canonical
• ✅ React 18 compatibility (Allow usage with react 18 #7377)

These items didn't make it into the release:

• Automate integration of authProvider and dataProvider for credentials Not crucial
• Change GraphQL Data Provider approach to avoid relying on runtime introspection (Make graphQL provider rely on code generatoin rather than runtime introspection #6639) Will be done in a minor release
• Update BooleanInput signature (BooleanInput onChange return boolean instead of event #4273)
• Use MUI Datagrid instead of our own Maybe in a future version
• Write codemods to facilitate the upgrade

We won't break BC for another year or two after 4.0, so we'd better wait to incorporate the new major releases of our dependencies. This causes the following releases to be blockers:

• Selectors for react useContext (RFC: Context selectors reactjs/rfcs#119)

Timeline

Work on v4 started in September 2021, and is expected to end in early 2022.

Note: Please don't post comments with feature requests that don't need a breaking change here. React-admin releases new features on a monthly basis, and doesn't need a major release for that. This discussion is only for backwards-incompatible changes.

[smeng9]

Hi I have a question, what drives the decision to replace redux-form to react-final-form during v2->v3 and then switch to formik from v3->v4? License? Render speed?

I know the main interface of form components won't change much, but some of the attributes of the components may get changed.

[smeng9]

You also mentioned removing redux-saga. Currently there are still a lot of parts related to the saga in the codebase, including handling of authentications and data fetchings.

Is the alternative going to be using react contexts? That is probably the only method to replace saga. Thanks!

[smeng9]

In terms of this major release, will ra-enterprise version also receive new versions in parallel? I am pretty interested in the paid version so I have so many questions to discuss here.

[fzaninotto]

Hi I have a question, what drives the decision to replace redux-form to react-final-form during v2->v3 and then switch to formik from v3->v4? License? Render speed?

The same reason: library maintenance. redux-form isn't maintained anymore, and react-final-form is taking the same path. some bugs in react-admin can't be fixed because they are caused by bugs in final-form that don't get fixed.

On the other hand, formik is actively maintained and has a positive contribution curve.

Finally, react-final-form has 6k stars on GitHub, while Formik has 26k stars. When we made the choice to go with final-form, they were at the same level.

Currently there are still a lot of parts related to the saga in the codebase, including handling of authentications and data fetchings.

No, 100% of the side effects are handled by pure React side effects and contexts in the curent codebase. The sagas are just here for backwards compatibility.

will ra-enterprise version also receive new versions in parallel?

We'll make re-enterprise modules compatible with 4.0 as soon as it's released. If this can be done without breaking change, then this will be a minor release, otherwise it'll be a major release.

[huijiewei]

react-hook-form

Suggest

[djhi]

It would probably be nice to introduce hooks to trigger side effects which could update the store. It would help implementing custom data providers methods which may have to update the data, delete it, etc.

For example see #5959. With a useDeleteFromStore or similar, it would be trivial to implement

[m4theushw]

The <AutocompleteInput /> could be rewritten to use the <Autocomplete /> from Material-UI. In V5 it will not be in beta anymore.

[wmwart]

Extend the permissions action to more components. In particular, the <Fields> and <Inputs> components.
A fairly common task is to restrict user fields based on access.
Now, each of my <Fields> and <Inputs> components is wrapped in an accessor function. This makes the components <List>, <Show>, <Edit> and others very cumbersome.
It would be nice if as many components as possible support the access property.
Or, for example, for example, to be able to specify access in the style of validation of both the form and individual fields.

[capJavert]

Replace react-final-form with formik

Did you think about integrating https://github.com/react-hook-form/react-hook-form instead of formik? react-final-form and formik are crazy slow and unoptimized when working with semi large and large forms (10+ inputs or array input).

react-hook-form is really fast with hundreds of inputs and also isolates rerenders based on the state chunks that changed. Main difference is uncontrolled approach but that can be solved with https://react-hook-form.com/advanced-usage#ControlledmixedwithUncontrolledComponents.

Aside from that APIs are similar (we recently replaced formik with react-hook-form in one of our projects with no issues).

People are already moving from formik based on the reasons above so maybe think about jumping to react-hook-form?

[ValentinnDimitroff]

It is not a huge difference but I was wondering why do you depend on classnames when material-ui (and probably some others) already depend on clsx ?

Passed my mind when thought about reducing dependencies list.

[fzaninotto]

@ValentinnDimitroff No idea when they migrated to clsx. When we started using material-ui, they were using classnames.

I guess we focus more on backwards compatibility and they prefer to move fast and break things ;)

[andrico1234]

You mention that you plan on removing redux-saga and saga-based side effects. While I don't pass through any customSagas to the Admin component yet, I am looking at ways to dispatch notification actions from whenever a specific event occurs. For instances like this useNotify isn't a viable option.

Is there a migration strategy for those that are using customSagas in such a way, or will the customSagas property still be supported?

[fzaninotto]

I am looking at ways to dispatch notification actions whenever a specific event occurs

Do like we do in the react-admin codebase: combine useNotify and useEffect.

[henrik-d]

Remove redux-saga and saga-based side effects

May I ask what lead to the decision to remove redux-saga? What was it used for and how is it replaced now?

[fzaninotto]

It was used for side effects, and we now use useSideEffect for that. Besides, when we first built react-admin, Redux was the cornerstone of the state and change management. Today, Redux isn't so central, and some newer parts of the framework simply don't rely on it at all (e.g. authentication).

As an example, the react-admin demo doesn't use saga at all.

[fzaninotto]

@sidescraper please don't post feature requests here. We're adding new features in minor versions. 4.0 will probably add no new feature, but just change the underlying layers that have become a problem. It's all about breaking backwards compatibility.

[rassie]

Does moving to formik mean that any custom forms will need to be rewritten more or less from scratch? Or will there be a compatibility layer for a couple of versions?

[fzaninotto]

The move to formik will be a breaking change, but for most custom forms, the required change will reduce to changing the package name as the APIs are mostly compatible:

-import { Form, Field } from 'react-final-form'; 
+import { Form, Field } from 'formik';

[zero-shubham]

what does the community think about react-hook-form ? I think it's more user friendly when compared to formik.

[smeng9]

I would prefer formik since it it introduces minimal breaking change

EDIT 8/3/2021:
After more evaluation of react-hook-form 5 month later after the initial post, it seems the react-hook-form's development is more active, and it also has smaller bundle size. We have already switched to react-hook-form on some other projects.

[lukin]

What do you think about removing extra styles? This change will make the components more clearer and compatible with the Material-UI API.

I will try to explain in more detail.

For example, when using <SearchInput />, I expect the position on the page to be similar to the <TextField />, without additional margin.

Or when using <SelectInput />, responsiveness sometimes breaks on small screens due to min-width.

Other components have similar additional styles. makeStyles can be overridden, but it seems to me that in some cases the components would be more convenient without them.

[fzaninotto]

@lukin I don't understand the problem you're trying to solve. Could you elaborate?

[fzaninotto]

@lukin If I understand your suggestion correctly this would break the default FormLayouts. Or do you expect these layouts to inject the custom styles?

[lukin]

@fzaninotto Yes, that's right. I often have to use custom complex form layouts. By injecting these styles into included layouts (e.g. SimpleForm, TabbedForm), field and input components would be more flexible.

[andrico1234]

Extend the permissions action to more components. In particular, the <Fields> and <Inputs> components.
A fairly common task is to restrict user fields based on access.
Now, each of my <Fields> and <Inputs> components is wrapped in an accessor function. This makes the components <List>, <Show>, <Edit> and others very cumbersome.
It would be nice if as many components as possible support the access property.
Or, for example, for example, to be able to specify access in the style of validation of both the form and individual fields.

@wmwart I know this isn't the best place for this message, but I just open sourced this handy package to do just that: https://github.com/andrico1234/ra-acl. It's inspired by Marmelab's ra-auth-acl, and adds hooks and declarative components.

[DataHippo93]

Please make HRM work with React-Admin!

#495

[VinayaSathyanarayana]

Please support next-auth as authentication provider

[fzaninotto]

@VinayaSathyanarayana Please don't post comments with feature requests that don't need a breaking change here. React-admin releases new features on a daily basis, and doesn't need a major release for that. This discussion is only for backwards-incompatible changes.

[fzaninotto]

@Romej We haven't planned to write an upgrade guide from 2 to 4. If you want one, I suggest you get in touch with Marmelab to buy some Professional Services.

[CezaryTarnowski-TomTom]

Hi, with the migration to 4.0 I've noticed that my app contains multiple nested views on entities that are dependent on other entities. A simple example would be groups and users that are parts of those groups, to attach a user to a group we're using route:
/#/groups/:groupId/users/create
for the list of users in the group we have:
/#/groups/:groupId/users
which we have defined as custom routes, it is working but it makes the groupUser resource handling substandard.
I've started thinking that maybe it would be good to have an ability to nest tags so that on the react-admin level some entities can be considered as dependent on others.
I'm wondering if you foresee such a use case, if this is something that you would like to be a part of v4 I could try to prepare a PR.

[fzaninotto]

@CezaryTarnowski-TomTom interesting use case, for which react-admin wasn't originally designed. But it should become more straightforward if you wrap your users page with a ResourceContextProvider.

As for your PR, could you elaborate on what you have in mind ?

[CezaryTarnowski-TomTom]

I would think about an ability to nest a users resource within groups:

<Resource name="groups">
   <Resource name="groupUsers" />
</Resource>

which would make the routes like:
#/groups/:groupId/groupUsers/ - for list
#/groups/:groupId/groupUsers/:id - for edit
etc...
that would also somehow set the groupId in the context of a groupUsers resource.
I'm planning to deliver such a feature and I believe that it could be easier to create that within the library itself, I could also use some of your expertise.

[fzaninotto]

@CezaryTarnowski-TomTom nice idea. I don't think this requires a breaking change, so it's something we can add later. Your PR will be welcome!

[WesleyKapow]

Would love to be able to modify a resource's routes as I'd like /resource/:id to point to show and /resource/:id/edit to point to edit. I believe this aligns with many conventions like seen in rails. From a user perspective, they could copy and paste id's into the URL and that should go to the show page!

From the doc:

The routing will map the component as follows:

/posts/ maps to PostList
/posts/create maps to PostCreate
/posts/:id maps to PostEdit
/posts/:id/show maps to PostShow

[TCM5]

*offtopic alert . Just for curiosity, have you guys considered using zero-installs philosophy?

[fzaninotto]

*offtopic alert . Just for curiosity, have you guys considered using zero-installs philosophy?

I don't know what it is, can you please elaborate?

[cuong-nguyen]

Thank you all contributors and @fzaninotto on this v4. We're using v3 for one internal project and we're starting new one in few weeks. Is v4 beta production ready? or should I stick with v3 for now? If v4 is not ready, any specific timeline as to when it will be? Thanks 🙏

[djhi]

No it's not ready yet. We plan to release a beta very soon though

[fzaninotto]

I've removed this item from the list:

• Change dataProvider.getList signature to accept operators in filters (filters?: Array<{ field, operator, value}>) (Update filter syntax to support operators #7235)

The rationale for not doing it in v4 is explained in the linked PR.

[fzaninotto]

I've removed this item from the list:

• Inject components instead of elements ([RFC] Replace injected elements by injected components #3246)

We're not ready for that and the tradeoff isn't clear - some might say that the trend goes the other way around.

[fzaninotto]

I've removed this item from the list:

• Manage open/closed menu state in Menu rather than Sidebar (Move control of sidebar width to its menu child #5575)

After a few tests, I can't implement it. The mui Drawer component requires a fixed width for its main content.

So we'll fall back to the theme (with a custom theme property) that developers can tweak to adjust the menu width. Unforty-unately, this will require a bit of documentation.

[fzaninotto]

Great news: we've published the first beta release for v4: https://github.com/marmelab/react-admin/releases/tag/v4.0.0-beta.1.0

Please test and report bugs, and regressions as new GitHub issues!

[fzaninotto]

I'll speak about the changes and new features of react-admin v4 in about a week from now, during a 30 minutes online event. It's free, so feel free to join if you're curious about the future major release of react-admin!

https://www.eventbrite.com/e/preview-of-react-admin-v4-tickets-274058445187

[giorgiPapava]

Hey,
thanks for this awesome tool for community. I'm wondering when v4 will be production ready and available on NPM. I will be starting new project in around 1 month and I don't think it would be good idea to start with v3. What would be needed to migrate from v3 to v4? Will there be migration guide?

[djhi]

Hi,

We released several beta already. As for the upgrade guide, it's here and the documentation is here

[giorgiPapava]

@djhi
Thanks 🥰 Is is planned when you will be releasing production ready version? Also is it safe to start implementing beta version? Will there be breaking changes from beta to production?

[fzaninotto]

We've announced a public release of react-admin v4 in April. As for the beta, we're following semver, so there should not be any more breaking changes since the stable release.

[TCM5]

Ohhh, I missed the V4 preview event at preview-of-react-admin-v4.

Can this be published on youtube or something else?

[fzaninotto]

We didn't record the presentation. But we'll soon publish a blog post with essentially the same content.

[DVGY]

@fzaninotto I saw just now that, your team will also remove redux. In our app, we are using custom reducers and our own state in the whole app to manage some data.

Can you pls answer these 2 questions taking into consideration the redux thing?

1. How hard will it be to upgrade our app to react admin v 4.0.0?
2. What are the things that we may need to change?

[fzaninotto]

@DVGY We've written an extensive Upgrade guide, it contains all the anwsers you need.

https://github.com/marmelab/react-admin/blob/next/UPGRADE.md#redux-is-gone

[fzaninotto]

We've published react-admin v4 today!

https://github.com/marmelab/react-admin/releases/tag/v4.0.0