Documentation on Recommended Forks

[SkyeHoefling]

What documentation page needs changing?

nvQuickTheme is a great theme building toolkit and takes a hard dependency on Bootstrap (which is a great idea). There are have been some 3rd party forks using using Tailwind CSS, Foundation, etc. As more forks are created targeting different frameworks it would be useful to have official recommendations from the nvisionative team on where to find forks for different frameworks.

What documentation section needs changing?

Add a new documentation section documenting where to find nvQuickTheme forks for different platforms. This will generate additional visibility to the different flavors of nvQuickTheme.

Proposed documentation change

See above

Describe alternatives you've considered

This may not be something that nvQuickTheme should be responsible as it can generate confusion on what is nvQuickTheme

Additional context

With the release of the Tailwind nvQuickTheme fork I am thinking of contributing my foundation 6 fork of nvQuickTheme.

[david-poindexter]

This is a great idea @ahoefling and I think you are spot on. nvQuickTheme and any other forks could collaborate on some great way to consistently showcase all the project options that follow the same underlying principles.

That said, you are tangentially touching on something I have been contemplating for a while now. I have been wondering if nvQuickTheme should transition to a pure CSS (no framework) approach and then essentially fork nvQuickTheme as we know it today to something like nvQuickTheme Bootstrap. Of course, the challenge with this approach can be maintaining synchronicity across all forks. Each framework has its own nuances and build requirements that make it challenging to fully standardize and keep stuff in sync.

[SkyeHoefling]

Happy to hear you and the team have been considering this already!

The reason why I haven't shared my fork is due to the difficulty on syncing up with the official nvQuickTheme toolkit. My recommendation is to create a core project that will have the build engine and standard files that really shouldn't change between the forks. Then the forks could include it as a git-submodule or npm package. The actual structure of the core project is up for debate.

Here is something that may work for a folder structure, I have identified files that should just be empty.

|-- containers
    |-- none.ascx
|-- menus
    |-- razor
        |-- RazorMenu.cshtml (Configure as placeholder to make it easier to implement or leave file empty)
        |-- menudef.xml
|-- partials
    |-- _header.ascx (file should be empty)
    |-- _footer.ascx (file should be empty)
    | -- _framework.ascx (file should be empty, it will be customized in the forked projects)
    |-- _registers.ascx
    |-- _includes.ascx (only include core specific references)
|-- src
    |-- assets
        |-- .gitkeep (let the forked projects decide on 3rd party tools)
    |-- fonts
        |-- .gitkeep (let the forked projects decide what fonts to include)
    |-- images
        |-- .gitkeep 
    |-- js
        |-- custom.js (this would be an empty file)
    |-- scss
        |-- components
            |-- _dnn.scss (DNN specific styles such as Module Action Menu, ideally in my proposal this would be broken to multiple DNN components)
            |-- _components.scss (move any framework specific styles to the framework folder)
        |-- framework
            |-- _login.scss (as an example this is where login styles should live, but not included in the core)
            |-- _framework.scss (the entry point for framework styles, this folder would contain specific styles for bootstrap, tailwind, foundation, etc.)
        |-- layouts
            |-- _layouts.scss (this isn't there, but it could be used to call multiple layout files)
        |-- mixins
            |-- _mixins.scss
        |-- pages
            |-- _globals.scss
            |-- _pages.scss
        |-- sections
            |-- _sections.scss
        |-- variables
            |-- _breakpoints.scss
            |-- _colors.scss
            |-- _spacing.scss
            |-- _type.scss
            |-- _variables.scss
        |-- .scss-lint.yml
        |-- _base.scss
        |-- style.scss
|-- default.ascx (remove the majority of the markup, but keep the partial references)

The challenge is taking changes from upstream with this folder structure. If a fork needed to pull the latest changes managing conflicts will be difficult. That challenge will make it less likely for fork maintainers to keep their projects up to date with the latest changes in nvQuickTheme.

An alternative to this, is identify the required files and add them as a npm package. This will completely isolate the fork changes from upstream. Creating an npm package will require a re-write of many of the build steps to properly copy the correct files to the distribution folder but it may be a better approach. It would allow us to remove all files from the above example that are considered 'core'. Managing upstream changes will be easier to just pull the latest, then you would just need to ensure your build scripts merge correctly.

If we take the example above and consider it as a npm package our forked project structure may look something like this

|-- menus
    |-- razor
        |-- RazorMenu.cshtml (Configure as placeholder to make it easier to implement or leave file empty)
        |-- menudef.xml
|-- partials
    |-- _header.ascx
    |-- _footer.ascx
    |-- _framework.ascx
|-- src
    |-- assets
        |-- .gitkeep (let the forked projects decide on 3rd party tools)
    |-- fonts
        |-- .gitkeep (let the forked projects decide what fonts to include)
    |-- images
        |-- .gitkeep 
    |-- js
        |-- custom.js (this would be an empty file)
    |-- scss
        |-- framework
            |-- _login.scss (as an example this is where login styles should live, but not included in the core)
            |-- _framework.scss (the entry point for framework styles, this folder would contain specific styles for bootstrap, tailwind, foundation, etc.)
        |-- layouts
            |-- _layouts.scss (this isn't there, but it could be used to call multiple layout files)
        |-- .scss-lint.yml
        |-- _base.scss
        |-- style.scss
|-- default.ascx (remove the majority of the markup, but keep the partial references)
|-- node_modules
    |-- nvisionation
        |-- nvQuickTheme
            |-- containers
                |-- none.ascx
            |-- partials
                |-- _registers.ascx
                |-- _includes.ascx (only include core specific references)
            |-- src
                |-- js
                    |-- custom.js (if there is any core JS files, it could go here)
                |-- scss
                    |-- components
                        |-- _dnn.scss (DNN specific styles such as Module Action Menu, ideally in my proposal this would be broken to multiple DNN components)
                        |-- _components.scss (move any framework specific styles to the framework folder)
                    |-- mixins
                        |-- _mixins.scss
                    |-- pages
                        |-- _globals.scss
                        |-- _pages.scss
                    |-- sections
                        |-- _sections.scss
                    |-- variables
                        |-- _breakpoints.scss
                        |-- _colors.scss
                        |-- _spacing.scss
                        |-- _type.scss
                        |-- _variables.scss
                    |-- .scss-lint.yml
                    |-- _base.scss
                    |-- style.scss

These are just thoughts and ideas, no real proposal here but thought it would give you some opinions to think through.

[david-poindexter]

Great thoughts @ahoefling - certainly some great stuff to chew on a bit and see where it goes.

[skrantzman]

Interesting concept. I have previously given some thought about how I might incorporate nvQuickTheme's new features and improvements into DNN_Tailwind down the road, and this suggestion has some merit.

As of now, for DNN_Tailwind, there could be some issues though. Seeing Tailwind CSS does not rely heavily on custom CSS, I thought SASS would be overkill for this project. After much internal debate, I deviated from the above structure, by removing the SCSS folder and replaced it with a CSS folder that contains slightly different content which is Tailwind specific.

I would be willing to make the necessary changes to DNN_Tailwind if a viable solutions is agreed upon. I am just not sure how this might be accomplished, while still meeting the needs of each particular framework's quirks.

[david-poindexter]

For right now, it would just be us three (@ahoefling + @skrantzman + me) to coordinate. If you guys would like to schedule a Zoom call at some point to discuss further, I'd be happy to host.

[skrantzman]

I am a bit of a hack, but I would be happy to help as much as I can. My schedule is pretty flexible so throw out some dates and times, and lets what's good for ahoefling, if he is willing.

FYI I am in Pacific Standard Time.

[SkyeHoefling]

Scheduling for me might be difficult, could we keep our discussion here on GitHub? It may be useful for us to list out the major features being used between the forks.