Recommended way to extend Snowdog/blank using Frontools

[Bartek Igielski]

The initial idea of LESS to SASS Magento UI rewrite was to simplify as much as I can. That's why I removed tons of variables, most of the files form variables directory and combined them together.

So my idea was to define all necessary variables in you theme, then pass them as parameters to mixins (overwrite mixins if necessary) and bind to own selectors.

I don't feel comfortable with using 1000+ variables to style a theme, that why I'm against this inherited from LESS lang idea of global scope variables, which might be nice for the project that looks almost the same as a Blank, but will be painful for developers and custom project (they will just ignore these variables, same as they ignore whole Magento UI, b/c is too complex, but not flexible enough in same time).

[mattgreenfield]

Yes i totally see what you mean, the UI library is scary and underused for that reason.

However if 'blank' uses the same mixin 5 times across the site and I want to change the padding in all those 5 places. I need to call that mixin again, in all 5 places. Or add new CSS to overwrite the padding value. Either way, I'm duplicating CSS.

I don't really know if there's a right or wrong answer, the problem stems from code out of our control!

[klaas_werkt]

I agree.

Indeed, the current LESS implementation of the Magento-UI library uses many variables and is complex and configurable. But, the Snowdog/blank theme does use this library, so it has a dependency on the Magento-UI library. And because of this dependency, the current implementation of the SASS theme (including this library) resembles the LESS origin quite a lot and caries along the same problems with variables. Whether they're globally declared or not declared at all, both cause a problem - either complexity or non-configurablily. Also, this theme is only a frontend theme, so support for backend elements could be dropped .. right? (***)

This SASS-theme has taken on the task of taking 2 hurdles at the same time:

- Replacing LESS by SASS (for faster compilation)

- Simplifying the Magento-UI library (removing variables from the global namespace)

1. If this theme would only tackle the "Replacing LESS by SASS" tingy, this would result in a theme that does have a lot of variables in the global namespace, but it would be quite easy to convert a current LESS theme into a faster compiling SASS theme. Also, new changes or additions to the Magento LESS theme can be ported quite easily to this theme.

2. If the Magento-UI library can be simplified and drop support for backend (***) than this theme could use a whole new base library that replaces the Magento-UI library and the problem that come with it. This requires a lot of work, testing and planning but could result in a very optimized theme.

3. The current direction seems one that only simplifies the Magento-UI library by removing its variables from the global namespace. (I may be overlooking other changes, please correct me if I'm wrong). However, I can't find a good alternative for the use of the variables in the global namespace, in the SASS theme Magento-UI library.

If I can't find a solution for 3. I'd prefer either 1. or 2.

Does this sound like a valid though? Can you guys relate to this?

*** I'm really not sure if support for backend can be dropped, this might conflict with future plans for supporting it in SASS

[Bartek Igielski]

I'm not planning any wider changes in this theme, b/c we started building a new one.

I'm aware of all these issues for a long time, but possible options are time-consuming and will not change this theme to something really great.

That's why we are building a new theme from scratch with the different approach in mind.

Answering your questions:

1.  We can remove backend (admin) related code - this project is standalone and never be part of the Magento core.
2.  Changes in Magento UI are not limited to variables, b/c there were weird or not possible to port to SASS parts of the code.
3.  Do I know what to do with this code to reduce duplication and not spend hundreds of hours rewriting them?
   
   Not really, but probably the simplest option will be to make this lib LESS-like (option 1) by adding back those 1000+ variables (option 1) and use it until we release our new project.

[klaas_werkt]

Hi Bartek,

It's important information and interesting to know that the current implementation of this theme is never going to be part of the Magento core and will someday be deprecated in favor of the newly build theme from scratch. I thought that Alan Kent was talking about this theme in his article, but I assumed incorrectly. Is there any more information about this new theme, such as milestones or a due date? I'm very much interested and would love to stay up to date! Maybe even help where I can

As for the current implementation - I get that this is not worth putting lot of time in and I agree that the LESS-like approach is the simplest way of adding configurability. When I have some updates on it I'll make a pull-request.

[Bartek Igielski]

Alan's article is now over 1yo, many things changes over this time.

That's my most recent speech about the state of M2 front-end from Imagine 2017 and it also briefly covers idea of our new project - https://magento.com/resources/how-magento-front-end-going-zero-hero

Our new project, codename Alpaca, is already open-source on Github, but it's not released (everything is on develop and feature branches), so you can't help us yet, but you might try to setup and understand the idea.
https://github.com/SnowdogApps/magento2-alpaca-theme

https://github.com/SnowdogApps/magento2-alpaca-ui-components

[klaas_werkt]

Thanks a bunch for the link to the Imagine talk. Great to see Alan Kent was there as well. I get where things are, and where they're going. Good to know that Snowdog will also keep supporting the current implementation of the SASS-theme for future stable release of Magento 2.

I'll keep an eye on the Alpaca project, great endeavours!