search

strapi / rfcs

RFCs for Strapi future changes
68 stars 33 forks source link

[V5]: FE APIs #56

Open joshuaellis opened 10 months ago

joshuaellis commented 10 months ago

Introduce typed imperative APIs to inject DocumentActions, SideBarPanels and DocumentHeaderActions as opposed to InjectionZones in V5.

You can read it here

Boegie19 commented 10 months ago

Can you give us examples of how the injection zone replacement would be UI wise?

Boegie19 commented 10 months ago

I like the idea but why remove the InjectionZones and not build this feture ontop of InjectionZones. so it can be an InjectionZones or documentActions, SideBarPanels and DocumentHeaderActions

Boegie19 commented 9 months ago

We also need an easy way for plugins to add the special zones you made to the plugin like you can do with injection zones.

t-fritsch commented 8 months ago

Thanks for this RFC, V4 was a huge step back regarding frontend customization, compared to the freedom offered in V3. If I understand it well, this RFC propose a new way to add components in some pre-defined places (especially the header and edit view). This is great but V5 should also provide solutions to not only "add" stuff, but also affect existing parts of the UI :

There are numerous issues/posts about this :

What is so frustrating with v4 is that the backend part can be customized quite fully : with routes, controllers, middlewares, services, we can do (almost) ANYTHING. This is perfect 🙌 And when you switch to the frontend part you only get a tiiiiiiny space to play with (and always adding stuff, not editing or removing). It's like switching from paradise to jail 😰😅

Please don't forget that if the developers that work with strapi are good enough to produce good backend code, we are also capable of doing some solid React Frontend development. I understand that it won't be possible in the very first V5 releases to match FE customization possibilities with the level of customization given BE-side, but please try to give us some freedom back 🙏

joshuaellis commented 8 months ago

Please don't forget that if the developers that work with strapi are good enough to produce good backend code, we are also capable of doing some solid React Frontend development.

No one's forgetting that, no one is saying that developers can't write frontend code. The issue primarily is it creates an unstable product where even the smallest changes we make can break other people's admin panels – you see this consistently with issues on the BE already. So what we're doing is weighing up customisation with stability because not every Strapi user modifies their product to such a high degree.

Hopefully, should these APIs be well received we can move to exposing more in the future because what we're doing is giving the ability to customise without compromising usability which is products core concern that I sympathise with.

Thank you for all your feedback though, it's well appreciated & we'll keep it all in mind!

t-fritsch commented 8 months ago

Thanks for your quick reply @joshuaellis ! I realize you maybe misunderstood my intentions : I wasn't trying to accuse anyone of anything. Sorry if I wasn't clear. 🙏

I'm just emphasizing that there is a HUGE gap between the liberty you give BE side and FE side, and this cannot be solved by locking FE developers on so small areas like injections zones (If I understood the RFC the new system is quite the same). I think we can all imagine the frustration it would raise if you did the same thing BE side ie. allow developers to add stuff only in small places of the API or BE code, but not to override/remove core things. This is exactly the same on frontend.

I also disagree when you say that "not every Strapi user modifies their product to such a high degree.". I think that modification of the dashboard for example is needed by almost every user, the fact that the majority of nowadays strapi users accomodate to that doesn't mean they don't need it. Same can be said about the menus, the default rendering of relations in list view, or the way dates are formatted, etc.

I understand that this is important to not break things on every update and I've not digged deeper enough in strapi core to know what the solution would be, I'll leave it to the strapi team, but I hope you'll find a way to give back to developers better control of the UI, and not only on empty places but on existing part of the UI 🫶