Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

My very own vision about the future of Volto #4670

Closed
pnicolli opened this issue Apr 10, 2023 · 2 comments
Closed

My very own vision about the future of Volto #4670

pnicolli opened this issue Apr 10, 2023 · 2 comments
Labels
05 type: question discussion Not for actual issues, but to discuss ideas

Comments

@pnicolli
Copy link
Contributor

pnicolli commented Apr 10, 2023

Why this issue

I have been thinking a lot about the current state of Volto. I started thinking about this sort of roadmap after a few rants (not only of my own) and several discussions, especially the one about a possible future based on a framework like Next that we had at Beethoven Sprint 2022. I wanted to dump all my ideas somewhere, since it's a topic too big to bring up in Volto Team meetings and also usually not easy to bring up at Sprints/Conferences since there's usually a lot of other actual work to do, so I literally couldn't find a better way to explain my ideas.

Some of this points have also seen some initial implementations already, and were also discussed separately, for example #4662 or plone.restapi-client, but I would really like to have some sort of roadmap for the feature written and discussed somewhere, and for now dumping ideas here seemed like the best option for me. Also, this issue is also to suggest having a little more discussion since the aforementioned implementations sometimes just pop out apparently out of nowhere, without at least a small discussion in the team. I needed to put this small criticism here since it's one of the reasons of this whole wall of text, but it's somewhat out of topic, my focus here wants to be the roadmap.

So, enough explanations and on to what I believe the future of Volto should be.

Framework

I tried some of the most famous frameworks out there and my belief is that Next is the best option out there for us. I read that another very good option for sites like the ones Plone is usually used for is Astro, but I haven't tried it. In fact, one of the main reasons why Next is the best option imho is the huge community, which is beneficial. I believe that using a framework with a large community behind is very important for a niche framework like Volto, in order to find the best answers when we work on the core. This is why I didn't even consider Astro. I considered Remix but it looks a little more application oriented in my opinion. In addition, Next features for images and fonts are a big plus for us.

Project structure

Volto nowadays is multiple things at once. The two big parts are the razzle + project configuration and components + styles. They should be split in separate things/repos/whatever. Like other frameworks, for example Next, we should have most of the code (the second part) as one or more libraries of components/configs/etc and a template/generator that creates a project configuration and a package.json and other files with all the necessary libraries. Volto itself should not be runnable like today, a generated project would be required but that's ok imho, because this way we should be able to achieve two things: simplify the core and make it easier to transition away from Razzle.

Actually, what would be awesome would be to create a Next project with the standard Next tools and then just add Volto to it. This would be neat.

Next, Tanstack Query, TypeScript

If we manage to split the project like I described above, changing the moving parts should be easier to plan and to execute. For example: once the components library is fully separated, integrating everything in Next should be pretty easy (doesn't mean it takes a short time anyway).

Tanstack Query and TypeScript, imho, are those things that will take plenty of time but will bring proper benefits. They glue all other pieces together, because they work very well with Next. I would really like, on this topic, to have OpenApi in the backend in order to be able to spin up a backend and generate proper typings for the rest api, and also a Tanstack Query client can be autogenerated. Also, Zod for api response validation is an amazing tool.

Implementation details

I would also like to suggest a few changes in the code standards we use and in the implementation choices.

  1. Styles should be co-located with components and CSS Modules should be preferred, with SCSS if needed. Next supports all of this out of the box, obviously. For example, a component should be in a folder, for example Login, which contains a Login.tsx file together with Login.module.scss and the needed tests and storybook stories. This enhances greatly future maintenance, styles can be easily found when changes are needed, lazy loaded during rendering if applicable and deleted without fear of impacting other components.
  2. I would go all-in with Next when the change happens, meaning the Volto components library should assume Next exists. For example, next/image should be used, as long as CSS Modules as explained above.
  3. I would probably not build the base components from scratch, since we can leverage well built, configurable and accessible libraries, for example bootstrap 5 or react-aria+tailwindcss or even shadcn ui which is build on radix ui, another good option. I have not fully made up my mind on this point, but I am more on the side of using an existing framework. The complexity of maintaining a full blown components library on our own is not to be underestimated imho. Bootstrap 5 looks a lot different than the other options I mentioned, I know, but it is the same used for Classic, it is actually pretty easy to include in React and to tree-shake (at least they say) and it is configurable with css custom properties, so it is a good candidate for cms ui imho.
  4. Of course by the time we get to this points, Semantic UI should already be gone

The final output

Basically my idea of a plan for a future version of Volto, let's say 18, should be switching to being a framework for Plone with Next. The stack should be:

  1. Next w/ TypeScript
  2. Zod
  3. Tanstack Query
  4. CSS Framework of choice. Tailwind CSS imho should have a way to be very easily added to projects, even if we decide to not use it in core.

Bonus: React Server Components for rendering views 😃

@ me anywhere to discuss, or find me at Beethoven Sprint

@pnicolli pnicolli added 05 type: question discussion Not for actual issues, but to discuss ideas labels Apr 10, 2023
@pnicolli
Copy link
Contributor Author

Closing this since this has been thouroughly discussed and a roadmap for the future of Plone (and Volto) is there and pretty much aligned with this.

@stevepiercy
Copy link
Collaborator

Where's the Volto roadmap published? Is this it? https://github.com/orgs/plone/projects/33

https://plone.org/why-plone/roadmap is not explicit, and only mentions a release schedule as being current. If that GitHub project is the link to the roadmap, then the plone.org Roadmap page should also be updated by someone who's piloting this ship.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
05 type: question discussion Not for actual issues, but to discuss ideas
Projects
None yet
Development

No branches or pull requests

2 participants