JointsWP
JointsWP copied to clipboard
JeremyEnglert
JointsWP 6: Supporting Multiple Frameworks
JointsWP has always included Foundation baked into its core, however, with the shift towards Flexbox & CSS Grid, many users are left wanting something a bit more "bare bones". Also, requirements vary from project to project and users shouldn't have to use a different workflow/theme just because requirements dictate a specific framework. That's why JointsWP 6 will allow users to use Foundation, Bootstrap or no framework at all.
However, we need to discuss the best way to handle this. When a user runs npm install the first time, they will be asked which framework they want to use. If a user selects a framework, we need to figure the best way to install those framework specific files.
Other themes use Composer for this, however, I think Node is our best bet as users will already be installing it to use the theme. However, there are two (maybe more) ways we can handle adding the framework specific files.
Option 1 - Separate Repos for Framework Specific Files
How it Works: when a user selects a specific framework, we make another call to Github to grab framework specific files. We also run an npm install to grab the actual framework and install it as a dependency.
This option is probably the most logical but comes with additional overhead of having separate repos to house framework specific files.
You can see how this would work here: https://github.com/JeremyEnglert/JointsWP/blob/6.0-dev/build/build.js#L59
Option 2 - Single Repo for All Files, Automatically Remove Unnecessary Files During Theme Setup
How it Works: the initial download will include all files for all of the frameworks we support. When a user selects a framework, we remove all of the files that are not specific to that framework.
I'm not a huge fan of this route. But it is nice because it keeps all of the files in a single repo.
Really looking forward to hearing what other people think or other potential routes we can take.
Hi @JeremyEnglert
Taking some thought on this I agree the longterm goal is separate repositories for framework-specific files as it opens the opportunity for third-party to create their own framework package to support additional frameworks or to be replacements of the JWP core framework components.
With that being said I can see the simplicity for the initial development to house all components in a single repo to ease development.
As you already have an example of how the first option would work and because it's the long-term goal it makes sense to continue that route regardless of option #2's simplicity for initial development.
I'll look into this further but feel the initial direction into modulated framework components makes the most sense.
Cheers
So my original idea was that even if Foundation/Bootstrap was included, the grid classes wouldn't be automatically added. The main reason for this is it allows us to support multiple frameworks and most people change these classes anyway.
But is that too big of a change? Will people expect those classes to be in place or will they be okay adding them on their own?
I'm all for that I would like to be able to include material design which has its own set of structural classes
ML
On Wed, Nov 21, 2018, 11:23 AM Jeremy Englert <[email protected] wrote:
So my original idea was that even if Foundation/Bootstrap was included, the grid classes wouldn't be automatically added. The main reason for this is it allows us to support multiple frameworks and most people change these classes anyway.
But is that too big of a change? Will people expect those classes to be in place or will they be okay adding them on their own?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JeremyEnglert/JointsWP/issues/367#issuecomment-440765357, or mute the thread https://github.com/notifications/unsubscribe-auth/AD11N9014nvtBjuQ-d1kXLr-i9HorXtjks5uxZo6gaJpZM4Xbmd1 .
I can foresee that resulting in alot of support of people not understanding why it's not working out of the box as they expect. I would suggest we build the wrappers which hold those structural classes as partials and have a bootstrap-partials and foundation-partials, etc folders which get moved into the project overwriting the existing skeletal partials on selection of a framework. This way each framework gets their own set of wrapper partials holding the expected classes. These can of course be replaced by the developer.