Roadmap Process

[artf]

Hi folks, welcome to the GrapesJS Roadmap discussion.

Here you can find the actual GrapesJS Roadmap project.

Here I'd like to explain what is the long-term vision GrapesJS is aiming for and how the Roadmap process is expected to work in order to help us reach our goals.

Goals

• GrapesJS is a framework for building web-based editors, not an end-user application.
  • It's up to the consumer to create the "user-friendly UI" of the editor.
  • As a framework, our goal is to provide the ability the replace the default UI, if one exists.
• The core should be as lean as possible.
  • Provide only strictly necessary functionalities that could be used across different application domains.
• The core should be as headless as possible.
  • You don't need UI components if you're running GrapesJS server-side
• The core should be extendable.
  • It should be possible to add new functionalities or extend the existing ones.

The process

Here it's explained how the GrapesJS Roadmap process works and what are the necessary steps required to bring your suggestions into the project.

The Roadmap process, at a high level, is divided into two parts, the first one is the Roadmap Suggestions discussion category, which will be used to collect and vote for new suggestions from the community, and then there is the Roadmap Project which will provide the status of the accepted suggestion.

From suggestion to production

1. Open a new discussion in the Roadmap Suggestions category.

   • Specify, in the title, the type of suggestion you'd like to bring in:
     • Feature Request, title: [Feature]: ....
     • Documentation to add/improve, title: [Docs]: ....
     • WARNING: no bugs, those are already handled in the Bug report from GitHub Issues
   • Describe your suggestion as much in detail as possible.

2. Now people can comment and vote on the suggestion before bringing it into the Roadmap.

   • Use the default voting mechanism provided by GitHub Discussions.
     

3. The suggestion should reach at least 15 votes before being evaluated and accepted for the Roadmap.

4. Once the suggestion reached the minimal amount of votes, it will be evaluated and moved into the Roadmap.

5. The suggestion can now start its development cycle.

   • Accepted: here we can discuss all the necessary information in order to start working on the suggestion.
   • In progress: the suggestion is in development.
   • In review: a PR is opened for the suggestion and it's in the review process.
   • Done: the suggestion is now merged and will be available in the next release.

If you have any questions/suggestions about the Roadmap process, you can post them directly here in this discussion post.

[lexoyo]

Great thank you @artf that's very clear and in the free software spirit

Concerning breaking changes / versions, do you have a process or vision ? As a framework it is important that it is a good balance between go fast and don't break applications too often ;)

Thank you for this, your leadership is inspiring

[artf]

Thank you @lexoyo I don't have yet a clear process of versioning, besides switching to a real semantic versioning one day, we're still in v0.* stage where breaking changes are indicated via minor updates.

At the current state, we're a bit far from the designed goals (eg. a lot of stuff has to be moved away from the core), and the closer we get there means the introduction of breaking changes.

[tahsin352]

when v0.* will become v1? do we have any plan for stable release?

[artf]

Do not have a plan yet to switch to v1.*, probably the package name itself will be moved to a new name (eg. @grapesjs/core)

[luisalvarado]

Thank yo so much for the information artf.

[awesome1128]

Can I know how to use this library in Laravel v10?
Please let me know, thanks

[artf]

Please @awesome1128 don't be that guy, avoid posting off-topic questions here

[ronaldohoch]

Thank you @artf 👏

[glaprida]

Hi @artf , I have developed a Dynamic Content / Collection Lists and Items / Repeater component. (the same feature is called by various names on different existing builders... Elementor, Framer, Webflow, Wix, etc).

It is a feature for my own implementation of GrapesJS, and it is build upon it.

I see on Roadmap you marked DataSources as High Priority and Large size. As far as I understand, what I built is pretty close to what you want to build (with the obvious exception that you want to build it INTO the framework and my implementation is built UPON it).

Anyway, I'm open to share it with you if you are interested (or at least curious).

The way it works for the user, is the following:
The user drags the Collection List component, and can choose a Source from its traits. (which fetches data from an api with the selected source)
Once a Source is chosen, Collection Items will be appended to the Collection List, matching the amount of items in the fetched data.

Then the user can drag any element intro any Collection Item, and it will be automatically synced to all other Collection Items (pretty much like symbols).

In the case of text elements, the user can type any static text, and it will be synced across all instances. The same with any styling, attributes or classes. (Still pretty much like symbols)

But the user can also choose a Source for each individual item, matching the keys of the fetched data.
For example, if the Source of the Collection List was Products, the data might look something like this:

data = [
  {
    id:1,
    name: 'Product #1 name',
    description: 'Sample product description',
    price: 120,
    stock: 4
  },
  {
    id:2,
    name: 'Product #2 sample name',
    description: 'Sample product description 2',
    price: 220,
    stock: 1
  },
  {...more product objects}
]

In this case, the user will be able to choose between Id, Name, Description, Price and Stock as a Source for the text element. (Some keys could be obviously be filtered out to make more sense).

If a text element inside a Collection Item has a Source, then it will show the corresponding value instead of a static text (eg. for Name, the first item will show "Product #1 name" while the second will show "Product #2 sample name").

There are also filtering, sorting and limit options for the entire collection; as well as switching the UI State to be able to edit how the Collection List would look like if there were no results. (the options on that select are "Items" and "Empty")

Here are some screenshots.

[artf]

That's awesome 👏
Indeed the data source item on the Roadmap was related to building that kind of functionality natively, at least from the business logic point of view.

I created a related discussion here #5956 where we can speak/share more about it (here it's kind of off-topic).