Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Customizer going forward #3

Open
erikmellum opened this issue Feb 10, 2016 · 1 comment
Open

Customizer going forward #3

erikmellum opened this issue Feb 10, 2016 · 1 comment

Comments

@erikmellum
Copy link
Contributor

@kball @gakimball @zurbrandon @zurbchris It's important that a resolution is reached regarding the customizer. The team might already be implementing a solution, in which case I placed some useful JSON files at the bottom of this comment. We are running into regular issues due to a lack of communication. The customizer depends on the following:

  • gulpfile.js (and the .js files within the gulp directory)
  • scss/foundation.scss
  • scss/settings/settings.scss
  • *.js within the js folder (just the file names need to remain the same)

There are two possible resolutions.

  1. Whenever these files are modified, the customizer is tested and updated appropriately before release
  2. The customizer is rebuilt using a "build up" approach which will reduce the dependencies

Lets examine these resolutions separately.

Option 1: Communication, testing and updating the customizer before releases

The issues that have broken the customizer recently are:
  1. Adding require('child_process').execSync to deploy.js
    This is a problem because all require statements are replaced with new relative file paths that point to the node_modules directory for the most recent build. This replace does not have the ability to take into account native modules vs modules within a node_modules directory. Adding native modules is not a problem if I (or the maintainer) are made aware before release. The fix was a single line of code.
  2. Replacing minifyCss with cssnano
    This is a problem because gulp deploy:custom depended on minifyCss, and was not updated. The fix was just to replace the reference to minifyCss with cssnano.
  3. (No Grid Issue)[https://github.com/Foundation for Sites Custom Download With No Grid Not Working foundation-sites#7819] caused by
@if not $flex {
    @include foundation-grid;
  }
  @else {
    @include foundation-flex-classes;
    @include foundation-flex-grid;
  }

This is a change in the way scss is included, and the customizer needs to be updated to resolve this.

I am happy to maintain the customizer, and perform all the necessary updates before a new release
However, it is unclear to me what solution ZURB wants to pursue.

Option 2: Rebuilding the customizer with a "Build up" approach

If the customizer were rewritten to use a build up approach, some of the problems above could be avoided. Lets look at which files would be built up, and what would remain the same.
Files to build up

  • gulpfile.js (build destinations)
  • foundation.scss

Files to edit

  • settings.scss

Files to remove

  • js files not included in the input submission

What can we draw from this "Build Up" approach

  • Any changes to the gulpfile in the foundation.scss repository would not necessitate code changes in the customizer.
  • Any changes to the foundation.scss file would not necessitate code changes in the customizer
  • Changes to the way components are @included, .js filenames, settings lines, would still require changes to the customizer
Conclusions

The build up approach can reduce the need for communication, and prevent some of these issues. I would be happy to build this out for ZURB. Given that Foundation is open source, I would be open to donating my time to this project. If that is what you would like to do, please let me know and I will begin. If that is not your desired course of action, I included the most pertinent JSON to rebuilding the app entirely. This JSON basically contains the mappings between the input values, and each of the files that would be either built up, or edited.

Regardless of your decision, please communicate with me before the next release if a solution has not yet been built out. I know you guys don't like seeing the customizer break, neither do the customers, and neither do I. If you communicate with me before the release I can do all of the testing necessary to ensure that we have a smooth upgrade on the customizer page. I would be happy to donate time before every release to maintain the customizer in its current state. This would require the least amount of time and effort out of all the solutions. The main requirement boils down to communication. I certainly want to give the team at ZURB the means to proceed with the course of action they think best, so if there are any questions please let me know and I will do my best to help.

Input values from html form submission
[
   "grid",
   "flex_grid",
   "typography",
   "button",
   "forms",
   "visibility_classes",
   "float_classes",
   "accordion",
   "accordion_menu",
   "badge",
   "breadcrumbs",
   "button_group",
   "callout",
   "close_button",
   "drilldown_menu",
   "dropdown",
   "dropdown_menu",
   "flex_video",
   "label",
   "media_object",
   "menu",
   "off-canvas",
   "orbit",
   "pagination",
   "progress_bar",
   "slider",
   "sticky",
   "reveal",
   "switch",
   "table",
   "tabs",
   "thumbnail",
   "title_bar",
   "tooltip",
   "top_bar",
   "motion_ui",
   "interchange",
   "magellan",
   "responsive_menu",
   "responsive_toggle",
   "toggler",
   "abide",
   "equalizer"
 ]
Mappings from values to scss includes
data.includes = {
    "grid":"@include foundation-grid;",
    "typography":"@include foundation-typography;",
    "button":"@include foundation-button;",
    "forms":"@include foundation-forms;",
    "visibility_classes":"@include foundation-visibility-classes;",
    "float_classes":"@include foundation-float-classes;",
    "accordion":"@include foundation-accordion;",
    "accordion_menu":"@include foundation-accordion-menu;",
    "badge":"@include foundation-badge;",
    "breadcrumbs":"@include foundation-breadcrumbs;",
    "button_group":"@include foundation-button-group;",
    "callout":"@include foundation-callout;",
    "close_button":"@include foundation-close-button;",
    "drilldown_menu":"@include foundation-drilldown-menu;",
    "dropdown":"@include foundation-dropdown;",
    "dropdown_menu":"@include foundation-dropdown-menu;",
    "flex_video":"@include foundation-flex-video;",
    "label":"@include foundation-label;",
    "media_object":"@include foundation-media-object;",
    "menu":"@include foundation-menu;",
    "off-canvas":"@include foundation-off-canvas;",
    "orbit":"@include foundation-orbit;",
    "pagination":"@include foundation-pagination;",
    "progress_bar":"@include foundation-progress-bar;",
    "slider":"@include foundation-slider;",
    "sticky":"@include foundation-sticky;",
    "reveal":"@include foundation-reveal;",
    "switch":"@include foundation-switch;",
    "table":"@include foundation-table;",
    "tabs":"@include foundation-tabs;",
    "thumbnail":"@include foundation-thumbnail;",
    "title_bar":"@include foundation-title-bar;",
    "tooltip":"@include foundation-tooltip;",
    "top_bar":"@include foundation-top-bar;"
  }
Mappings of input values to javascript files
  data.js={
    "accordion":"foundation.accordion.js",
    "accordion_menu":"foundation.accordionMenu.js",
    "drilldown":"foundation.drilldown.js",
    "dropdown":"foundation.dropdown.js",
    "dropdown_menu":"foundation.dropdownMenu.js",
    "off-canvas":"foundation.offcanvas.js",
    "orbit":"foundation.orbit.js",
    "reveal":"foundation.reveal.js",
    "slider":"foundation.slider.js",
    "sticky":"foundation.sticky.js",
    "tabs":"foundation.tabs.js",
    "tooltip":"foundation.tooltip.js",
    "interchange":"foundation.interchange.js",
    "magellan":"foundation.magellan.js",
    "responsive_menu":"foundation.responsiveMenu.js",
    "responsive_toggle":"foundation.responsiveToggle.js",
    "toggler":"foundation.toggler.js",
    "abide":"foundation.abide.js",
    "equalizer":"foundation.equalizer.js"
  }
Values from input settings fields
  data.settings= [
    "column-count",
    "column-gutter",
    "max-width",
    "primary-color",
    "secondary-color",
    "success-color",
    "alert-color",
    "body-font-color",
    "header-font-color",
    "global-radius",
    "text-direction"
  ]
Mappings from settings values to text in settings.scss for replacement
  data.settingsLocators= {
    "column-count":"$grid-column-count: 12;",
    "column-gutter":"$grid-column-gutter: 30px;",
    "max-width":"$global-width: rem-calc(1200);",
    "primary-color":"$primary-color: #2199e8;",
    "secondary-color":"$secondary-color: #777;",
    "success-color":"$success-color: #3adb76;",
    "alert-color":"$alert-color: #ec5840;",
    "body-font-color":"$body-font-color: $black;",
    "header-font-color":"$header-color: inherit;",
    "global-radius":"$global-radius: 0;",
    "text-direction":"$global-text-direction: ltr;"
  }
Mappings from inputs, to the text that would be used to replace a given setting (used to construct new setting)
  data.settingsText= {
    "column-count":"$grid-column-count: ",
    "column-gutter":"$grid-column-gutter: ",
    "max-width":"$global-width: ",
    "primary-color":"$primary-color: ",
    "secondary-color":"$secondary-color: ",
    "success-color":"$success-color: ",
    "alert-color":"$alert-color: ",
    "body-font-color":"$body-font-color: ",
    "header-font-color":"$header-color: ",
    "global-radius":"$global-radius: ",
    "text-direction":"$global-text-direction: "
  }
Mappings from input setting values to the prefixes used for these settings (used to construct new settings)
  data.settingsPrefix= {
    "column-count":"",
    "column-gutter":"",
    "max-width":"",
    "primary-color":"#",
    "secondary-color":"#",
    "success-color":"#",
    "alert-color":"#",
    "body-font-color":"#",
    "header-font-color":"#",
    "global-radius":"",
    "text-direction":""
  }
Mappings from settings input values to setting suffixes (used to construct new settings)
  data.settingsSuffix= {
    "column-count":"",
    "column-gutter":"rem",
    "max-width":"rem",
    "primary-color":"",
    "secondary-color":"",
    "success-color":"",
    "alert-color":"",
    "body-font-color":"",
    "header-font-color":"",
    "global-radius":"px",
    "text-direction":""
  }
@paxperscientiam
Copy link

It's important that a resolution is reached regarding the customizer.

I agree. I've been working on improving foundation-cli. I had mentioned to another member that it would be cool if foundation-cli could hook into customizer is some way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants