Make Beans Framework Agnostic

[hellofromtonya]

Our core philosophy is to empower web developers by creating an environment where they can rapidly develop and have seamless branding and user experiences.

Right now, UIKit is deeply integrated into Beans. We will want to pull it out of the framework, thereby allowing a developer to pick and choose what UI framework s/he wants including rolling his/her own.

As part of this task, we'll need to decide whether to make UIKit a separate plugin or package it with Beans. Either way, we'll provide the means via configuration for a developer to turn it on.

[hellofromtonya]

This shift will then allow our Community to create add-on plugins or components for other UI frameworks such as Foundation, Bootstrap, Semantic UI, and any others now and into the future.

It provides maximum flexibility for the developer or site owner to assemble the site they need.

[hellofromtonya]

Whether UIKit remains within Beans or becomes a separate plugin, we will need to create Gutenblocks for the components.

[ibes]

As posted on Slack:

For v2 there is the idea (https://github.com/Getbeans/Beans/issues/51) to make Beans Framework agnostic by offering framework support via packages or plugins. Is there already and idea how to manage the plugins?

I am trying to put my head into a couple of best practises right now and (without a concrete and real issue right now) thinking about writing some extention / plugin / reset for tweaks that we might want for Beans so we can use it alongside Beans in multiple projects. To make clear again: I do preparation - there is not yet a clear thing I need.

So the question: How could that framework extentions be organized? We have just two layers in the theme metapher: parent and child. So there can't be an other layer in between them two.

So there could be a build process needed - which is not typical in WP. There could be starter themes offered for each framework - that doesn't sound like a good idea, because it likely breaks updates

So I guess extentions will need to be plugins maybe mu-plugins. Or they need to be delivered via Beans.

If the extentions are delivered coupled with Beans that is likely not a good idea. There should be a decoupling so that random people could start and build another adapter for another framework/tool. And extentions should have there own release circles to be able to fill the gap between Beans (that also handles the WP developments) and the Framework.

So I guess plugins will be the thing.

Plugins can

• do filters/actions so eg change classes etc.
• enqueue assets ( css, js )
• so, yes, that should work

If there is an answer to my kind of question (which is more a thought process, I guess) that can also happen in the github ticket

--- Tonyas reply ---

Hey @ibes, Feel free to add to the Issue #51 so that we can retain the discussion.

What we’re thinking about is this:

1. We’ll have different plugins for different types of UI frameworks.

2. I started the Beans UIkit plugin which would have UIkit 3, all scripts, Sass and LESS files, and Gutenblocks too.

3. Then as a community, we can build additional plugins off of the Beans UIkit model. We could have ones for Zurb, Bootstrap, etc.

I think it’ll be good to build one as a community, get it the way we all want it with Guten blocks, and get it out into the wild. Then we can build more of them using it as a template/boilerplate.

What do you think?

[ibes]

How will the plugins structured?

Beans need to have some generic HTML / CSS classes.

Than the plugins will modify that generic HTML / CSS classes to fit the framework.

And the child theme may extend / modify that code.

Beside of that the plugins could ship the CSS and JS. But that could also be a job for the child theme (maybe there should be starter themes for every framework that is supported).

Thinking about execution order.

We need this execution order

• Beans (Parent)
• Plugin
• Child-Theme to add modifications.