Grapesjs: How to contribute (currently tweaking Style Manager)

[BryceBubbles]

@artf
Hi Artur

Firstly, congrats on being awesome! When I found the GrapesJS website, I couldn't believe a project like this actually existed (and without me knowing already). An opensource web builder, with a great API, and already full of amazing features! It's like a dream come true, so thanks for all your work - very obviously a lot of work.

I'm planning to use GrapesJS for rapid prototyping of websites, and may integrate it with a CMS for both template development and client editing. So I'll be doing a bunch of development on GrapesJS for my personal use cases.

But I'm keen to find out how best to go about that development, in order that appropriate parts of what I do could be pulled back into the project, if you're interested?

For personal use I know I could just do a lot of configuration via the API (it's powerful, very well thought out, and the docs are good). And then some things will be best as plugins (not sure of the possibilities/limitation here yet). But then sometimes it's just easier (better?) to dive into the source and add features that could benefit others.

My current focus is expanding the Style Manager:

• More CSS - handle as many of the well supported CSS properties as possible by default (mostly via changes to PropertyFactory.js - don't think I've ever seen so many switch case's lol).
• Layout/Styling - tweaking the layout to be more compact and easier to modify via CSS or possibly some API settings (mostly via _gjs_style_manager.scss).
• Usability - adding various usability tweaks (working mostly in PropertyView's and domain_abstract ui)

I can list more specific features I'm adding if you're interested.

In the above cases, is working in src and doing pull requests good for you, or would you rather people leave the core to you and add functionality via plugins? I'm kind of new to collaboration via github.

Other things I'd like to see - that I might be able to work on if you're not already:

• Handling Media Queries - I've seen you mention elsewhere that you have plans for this. From my point of view this is the most needed feature. Is it something you plan to add soon? Would you integrate management of breakpoints with the Devices Manager? I can see how that might be easier, but I think it needs to be separate?
• Complex Selectors - a lot can be done with just classes, and it sort of forces an OOCSS paradigm, but sometimes tag selectors and nth-child are good to have. But failing that, actually just being able to modify a child based on the state of an ancestor would be good.
• Html/body/head - being able to style/modify html and body, and add stuff to head.
• Template Loop Tags - you mention in the readme that GrapeJS was designed to speed up the creation of dynamic templates, and you show simple {{var}} tags. I can see how that would work, but how might something more complex like twig loop tags work? Actually I'd be keen for something similar to Webflow's dynamic block, but with a way to hook it up to any CMS.

That's all for now.
Thanks for your time.
Bryce

[BryceBubbles]

Oh wow, I see that media queries are possible already, awesome, and handled by Device Manager. It's just not so obvious in Style Manager and you can't tell what's happening inheritance wise for each CSS property.

It would be awesome if media queries could be decoupled from Device Manager, so that more complex media queries can be used on a per selector basis.

Would also be cool if Device Manager had a height property.

[artf]

Hi @BryceBubbles, thanks for your kind words, really appreciate and glad to hear you're willing to contribute.
First of all, we're open to any feature proposal and we can discuss it directly here if it makes sense to add it to the core or via plugins (when possible). Style Manager is one of the modules with a wide range of stuff to improve, starting, for instance, from refactoring some methods to make it easier to extend.

• More CSS - PropertyFactory was made to facilitate some properties creation and, obviously, more is better, but it'd be insane cover all needs, therefore, I think making it extendable is a much wiser move.
• Layout/Styling - agree, I've already started refactoring few styles but there is still a lot to do
• Usability - I'd really like to make style property types extendable (for instance, like Traits) and this involves also PropertyView refactoring.
• Complex Selectors - definitely agree, I just like the class-based approach because it's highly comprehensible also by non-tech people (GrapesJS somehow born with this ideology), but some kind of "PRO level mode" might enable typing of selectors just by input text.
• Html/body/head - At the moment you can inject styles and scripts via [canvas configuration] (https://github.com/artf/grapesjs/blob/dev/src/canvas/config/config.js) but I have to adjust how the main component wrapper is handled (which is the body in most cases) and make it easier to style.
• Template Loop Tags - The main idea was to have fragmented templates, where variables, or loop of variables, are replaced dynamically and rendered via a server script. I haven't any example to show but I'm working on this :)

Thanks for your interest