New version questions & thoughts (v4)

[Aurelsicoko]

@gustavpursche

Graphql

• Will the graphql output be the same between v3 and v4 or do you expect many changes there?
• Do you think it will be possible to disable the graphql Pagination?
• Do you expect performance improvements for graphql?

• About the GraphQL output, we didn’t validate the format yet, please follow closely the RFC, we just published the REST API RFC and you can see we introduced several breaking changes to introduce metadata information (count, page).
• Why would you like to disable the pagination? Would it be the same for the REST API? Feel free to share your though on the RFC to discuss the topic with the Core team.
• Yes, and not only on GraphQL. We are fetching too many times the same entry right now, and even the relational entries sometimes when not necessary. We plan to refactor almost from scratch the GraphQL plugin.

@gustavpursche

Plugins

• Do you aim for a stable plugin system with v4, or do you consider it a draft?
• Do you expect live reload / HMR for plugin developers?
• Since you create a nice way to add custom fields: are you planning on supporting custom fields in the i18n plugin?

• The Plugin API will be released under Beta this summer, and we expect a Stable version at the end of Q3 (September/October). The growth of the ecosystem is really important to us, we want to let everyone a creative space to express their ideas through plugins. Currently, the current way we handle plugins doesn’t work well as you have to override instead of extending files. That’s why we developed the Internationalization feature as a plugin to test ourselves where we should open the API and let plugins interact with the product lifecycle.
• The Core team already developed a custom Webpack configuration to make it more performant when developing a plugin (removing most of the translations and unnecessary plugins from the build to make it fast). Our main goal is to switch on Webpack 5 and reduce the build size. I’ll let @alexandrebodin answer for the live reload and HMR.
• Custom fields are more complex than we could imagine. Are we talking about custom fields or custom components? The idea is to split each type of field into different packages with front-end and backend logic in it, but unfortunately, it isn’t planned in the first iteration.

@gustavpursche

Database Layer

• Do you think about global content-type wide lifecycle hooks? (for plugins like algolia, which want to synchronize content or create revisions of everything …)
• Do you think you can offer a nice migration path, or do you expect a lot of manual labour?
• Will it be possible for custom fields to store data in different DB columns or as Database Level data formats? (Storing JSON for example)
• Are you planning on having validations in the CMS UI?

• What’s the difference with the webhooks? You can easily do something similar by creating a custom route, set up a webhook that calls the route, and do a specific action.
• We will offer a way to easily migrate from v3 to v4. Then, with the introduction of automatic migration, no more manual migrations should be needed.
• As we don’t plan to implement the custom fields in this first iteration, I cannot give you an answer.
• Yes, it’s also something the Design System will introduce. The required and optional inputs will be more visible. The errors returned by the API will be clearer too. It’s actually one of our weaknesses and we really want to improve that part.

@gustavpursche

Design System

• Do you have some drafts, how the dynamic zones will look like? For our editorial team, this is a crucial area and currently very hard to work with if content pieces become long. I’d be happy to provide some design feedback as soon as you have something there … Main issues are visual hierarchy (find a component with a certain name) and controls (insert a new component anywhere, move components around …)
• Do you plan on having a spacing system here? Currently, plugins need to hard-code a lot of spacings. Would be nice, because it would blur the boundaries of core and plugins.

• Not yet, the designers and frontend engineers are working closely to take this unique opportunity to also improve the content editing experience. We will share exclusive screenshots in a few weeks to show you how the Edit view with Dynamic Zone will look like. We are aware of the issue you reported and we plan to fix them in v4.
• The Design System includes design tokens like spacing. Our goal is to write and share clear guidelines on how to build a plugin that fits with the Design System rules. It’s the main goal of focusing efforts on a design system right now. We want a consistent ecosystem, it starts with colors, spacing, font, etc.

@DevHunter

Does de V4 Support Typescript out of the box ?

• It isn’t part of the scope of the first iteration, but we know how impactful supporting TypeScrip could be. We know that a lot of you would like to customize their projects using TypeScript, I don’t want to make any promise here that we couldn’t keep, so it’s in our minds, not as a high priority but it will be implemented soon or later.