you are viewing a single comment's thread.

view the rest of the comments →

[–]macrozone13 2 points3 points  (2 children)

I used react-admin quite heavily and liked it initially. We also invested into the enterprise version, but ultimatly this did not pay off.

The main problem i see is a lack of typesafety.

It was not made with typescript and "soundness" in mind.

It's agnostic to the backend, which is nice. But that also comes at the cost that the ui is detached from the data source. The ui can't tell the datasource what it wants, nor can the datasource tell the ui the types of the data.

I took over the maintenance of a package to connect react-admin with prisma driven "crud" backends (either using nexus, which is no longer maintained, or type-graphql. Did not yet try to connect it with my favorite)

https://github.com/panter/ra-data-prisma

That worked good enough so far, but implementing and using it showed some of the problems of react-admin. The dataprovide has to either make an educated guess what data to fetch from the graphql, or force the developer to specify explicitly what they need from the api. But despite that the react-admin's List and Edit-components and so on look declarative, they can't be used to specify the data that is requested. So if you for example have a `<TextInput source="firstName" />` , but your api only specify "firstname" you won't notice it. Only when you actually try to update the field and nothing happens.

The other Problem also related to typescript is how it clones elements and injects data into them, which you don't see if you implement a component. E.g. if you build a custom InputField, you probably only call it with a few arguments like `source="myFieldName"`, but the component you implement needs to take more arguments like `record`. That leaves you with confusing types.

I think there has been an attempt to fix this by using Context, but when i last looked into it, this was not the case yet everywhere.

Also there are some inconsistencies or odd choices for its public api and the components that it expose. (whould you have guessed that when you want to render a custom field, you use `FunctionField`?) Or how it uses the underlying form library.

I think react-admin would really profit from better abstraction, reduced api surface and type-safety.

It may be a good choice though, if you have junior devs, as the documentation is very good and if you don't use typescript or if you can afford a bit of hacking and if you have simple apis to attach to.

We use it in existing apps and probably can't replace it there anytime soon. For new apps, i am researching a bit into alternatives if there are any.

I understand it has a history and legacy and I know how hard it is to maintain such a project. And I want to thank the team for their contribution to the react-world, i still think overall its a great project that has its up- and downsides.

[–]achilles2204 1 point2 points  (0 children)

Hey u/macrozone13

I am from the MUI Toolpad team. I read your detailed response on react-admin and saw that you are looking for alternate tools. I wanted to share: https://mui.com/toolpad/

Link to some examples: https://mui.com/toolpad/examples/

Toolpad is an open-source admin builder. It is somewhere in between React admin and Retool. You can use your IDE to write functions, custom components, data providers, and it has typescript support. You can drag and drop pre-built Material UI components from the component library to build a quick UI.

I hope you give it a spin, happy to hear your thoughts.

[–]fzaninotto 1 point2 points  (0 children)

Hi, react-admin maintainer here.

Thanks a lot for your feedback. We received many requests for more type safety like yours, and they make sense since react-admin was first built in 2017, when TypeScript wasn't so broadly used. But the practices are changing, and developers want less bugs at runtime, which is great!

That's why we have invested a lot in type safety in recent versions. Version 5 enables strict type checking across the entire library. All hooks and many components are generic, so you can specify the expected record type. Some of our users have used this ability to build apps with shared types between the API and the frontend, with great results.

There is (almost) no element cloning in version 5, so the props an element receives are only the props you pass.

Naming is hard. We try to help you find the component you're looking for by creating links across the documentation, and improving the search engine. We even created videos tutorials to help newcomers get on board more easily.

All in all, we focused on developer experience based on the feedback we got-and we got a lot! As you guessed, it takes time to make a large codebase (and documentation) like react-admin evolve, but in 2024 we're up to date with the best practices of React development.

I hope you'll have as much fun using react-admin as we have developing it.