Sorry for taking so long to publish this. Better late than never.
I mostly agree with what @SantosGuillamot and @mmczaplinski said so I’ll try to add something different.
I think it was great overall. The only thing for me was that we had a very long sprint without doing retrospective sessions before finishing it. That would have expossed some problems earlier, I guess.
Anyways, this is something we’ve already improved a lot during this time and we keep improving it.
Well, I didn’t like the experience of creating a process for every single gutenber block so much, to be honest.
One of the things was to overwrite Gutenberg default styles and it was a mess most of the time (it was already mentioned above). I think this took a lot of time and that happened mainly because we had a global style defined for most of the Gutenberg classes that didn’t match the design at all.
In the future, for the Gutenberg package I would implement it in a way there is a processor and a style for each gutenberg block separately, all exported in
libraries.gutenberg or something like that, so people just have to modify or overwrite them in their themes without having to deal with CSS conflicts (you could even want to overwrite the whole CSS). I know this would be a lot of work but I think it would really help Frontity users creating Frontity themes for Gutenberg.
Writing processos for adding styles to HTML classes feels strange also, like an extra step between CSS and HTML, but I know is the only way to do that.
Apart from that, it would be great to have some generic processors for basic tasks like adding styles and also to improve the Html2React API adding a better way to select elements and modify them (there is already a discussion about that here: Better class name tests in processors)