New version questions & thoughts (v4)

Discussions
1

Hey everyone, as you might know, we are currently working really hard on a brand new version of Strapi. As announced during the keynote at StrapiConf, we expect a Beta release this summer :sunny:

From our perpsective, the v4 and the Design System (with UI rebranding) are two different projects. Even if the v4 will use the new Design System and UI, it doesn’t mean they will be released under a stable tag at the same time. When we use the word “v4”, it means we talk about the technical aspects (database layer, Plugin API, files structure, data migration, etc).

So, feel free to express your opinions and ask any questions you have about v4. We would be very happy to answer them :hugs:

If you have technical questions or suggestions, please refers to the open RFC (link below).

Last but not least, the other goal of this thread is to keep and share an up-to-date list of curated resources about the v4 that you can find below.

ETA v4: End of October
ETA Design System: End of October

6 Likes
3

Thanks for the clarification on the question of the connection of the design language and the technical foundation. All Keynote had given me the impression that you’d change the technical aspects and the UI at the same time and call it v4.

My questions around v4 are mostly centered on the integration parts:

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?

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?

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?

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.

Apologies if these are too many :slight_smile:

In general from what you have shown already about the new design language I’m very excited. It looks way more modern. Also I really appreciate you are taking a11y serious in the new component library! I’m disappointed that you didn’t use the chance to introduce a responsive UI (which I’d say is mandatory in 2021), but I also see that you need the amount of changes under control …

8 Likes
4

Just a quick question please
Does de V4 Support Typescript out of the box ?

5

Any updates on the MongoDB support continuation by the MongoDB team as per MongoDB compatibility delayed on v4 - #63 by techbelle?

Just wanted to know where we stand in terms of MongoDB support as I have personally decided to move all future projects to PostgreSQL. I do understand the choice of moving away from NoSQL, totally makes sense to me from a business perspective. But I also have to support existing projects that have been launched using MongoDB and I have to figure out whether I should take matters into my own hands or wait a bit more and check if the support does arrive from the MongoDB team.

2 Likes
6

Hey all, we released one of the first RFCs (there will be many :wink: ) for the REST API:

Edit: Please keep in mind this is a draft RFC and isn’t entirely ready for full review as things are subject to change. (Sorry @alexandrebodin wasn’t aware).

1 Like
7
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
1 Like
8

Will it be possible to have relation fields required?

1 Like
9

Yes, it will be possible in the administration panel and also in the API to require a relational field.

3 Likes
11

I hope I’m not missing anything, but one thing I’d love to see if the ability with GraphQL find() to query not only based on ID, but also on any other field, especially relation.

For example, instead of doing something like:

const STRAPI_SHIP_Q = gql`
  query StrapiShip($shipId: ID!) {
    ship(id: $shipId) {
      id
      galaxyOfOrigin
    }
  }
`;

I would love to be able to do:

const STRAPI_SHIP_Q = gql`
  query StrapiShip($pilotId: ID!) {
    ship(pilot: $pilotId) {
      id
      galaxyOfOrigin
    }
  }
`;

Currently I would have to handle this with where on multiple-entry query, which is not ideal (notice the ships (plural) instead of ship (singular):

const STRAPI_SHIP_Q = gql`
  query StrapiShip($pilotId: ID!) {
    ships(where: { pilot: $pilotId }) {
      id
      galaxyOfOrigin
    }
  }
`;

and then handle the array of results to return a single entry.

Hope I’m making sense here.

Cheers to all for the awesome questions and awesome work, v4!!! :fire:

3 Likes
12

About GraphQL: have you any plans to implements subscriptions? It is a very interesting and useful feature from GraphQL we would use to create notifications and others, basically as a Webhook, yes, but integrated on the GraphQL API.

13

Not right away but it’s certainly on our minds and the v4 will certainly provide the framework level options to add something like that. We did have a few PRs that tried to implement it in v3 but generally the missing link was something like Redis which we didn’t have a good way to implement.

14

Hey Scott, did you take a look at the GraphQL API RFC? Feel free to suggest your idea and thoughts :slight_smile:

2 Likes
15

What’s about a easier way to create notifications for event emitted from, for instance, lyfecycles?

  • New user created.

  • New object from Collection Type.

Etc., most of them created from the API and not form the Admin Panel itself.

16

Is there currently, or will there be, a migration guide from v3 to v4?

1 Like
17

Eventually yes but not day one when v4-stable is released. Most likely we will release a migration guide around the end of Dec or sometime in Janurary.

18

Hi,

can you please provide v4 stable release tentative date?

19

End of nov, that’s as precise as I can be sorry