David Moore, Lead Architect - Twitter @Moorag81
Matthew Neil, Lead Front-end Developer - Twitter @Pho3n1x84
We've been discussing this for years! We don't have all the answers
We don't think Helix provides all the answers, but it's probably better than no Helix
We may severely annoy you and leave you more confused than when you came. We accept no responsibility for this. But we have provided beer as compensation.
Helix ≈ SOLID + Package Design + DDD
Text
Engineering software should not be a game of Jenga
Text
Yup. It's all there.... No. It's not a good idea
Text
You shouldn't need brain surgery to put on a hat
These make a lot of sense for OO languages like C#
Is JavaScript OO, Functional or Procedural?
What about CSS & HTML?
Does it Matter?
(Largely pilfered from Martin Davies Blog - http://sitecoreskills.blogspot.com/2018/08/sitecore-helix-distilled.html)
(Stable Dependencies Principle)
(Stable Abstractions Principle)
(Acyclic Dependencies Principle)
(SRP for packages)
(Reuse-Release Equivalence Principle)
(Common Closure Principle)
(Common Reuse Principle)
These principles are aimed at producing code bases with a low cost of ownership.
They are well established and have stood the test of time
Like design patterns. They are applicable to most languages and paradigms
They apply to both low level code and higher level architectures
You mentioned DDD!
"use naming conventions and language appropriate to the domain"
"group by function and not type"
What does Helix say about FE
Does this approach work?
Thinking About Compiled CSS
// placeholder
%fd-center {
margin: 0 auto;
max-width: 1200px;
}
.product-filter {
background: #fff;
&__inner {
@extend %fd-center;
display: flex;
}
&__search-pane {
flex-basis: 30%;
}
&__search-results {
flex-basis: 70%;
}
}
.newsletter {
background: #ccc;
&__inner {
@extend %fd-center;
}
}
.hero-banner {
background: linen;
&__inner {
@extend %fd-center;
}
}
.call-to-action {
background: #f1f1f1;
&__inner {
@extend %fd-center;
}
}
.product-filter__inner,
.newsletter__inner,
.hero-banner__inner,
.call-to-action__inner {
margin: 0 auto;
max-width: 1200px;
}
.product-filter {
background: #fff;
}
.product-filter__inner {
display: flex;
}
.product-filter__search-pane {
flex-basis: 30%;
}
.product-filter__search-results {
flex-basis: 70%;
}
.newsletter {
background: #ccc;
}
.hero-banner {
background: linen;
}
.call-to-action {
background: #f1f1f1;
}
SCSS Extends
Compiled Output
// mixin
@mixin center($siteWidth: 1200px, $spacing: 0 auto) {
margin: $spacing;
max-width: $siteWidth;
}
.product-filter {
background: #fff;
&__inner {
@include center;
display: flex;
}
&__search-pane {
flex-basis: 30%;
}
&__search-results {
flex-basis: 70%;
}
}
.newsletter {
background: #ccc;
&__inner {
@include center;
}
}
.hero-banner {
background: linen;
&__inner {
@include center;
}
}
.call-to-action {
background: #f1f1f1;
&__inner {
@include center;
}
}
.product-filter {
background: #fff;
}
.product-filter__inner {
margin: 0 auto;
max-width: 1200px;
display: flex;
}
.product-filter__search-pane {
flex-basis: 30%;
}
.product-filter__search-results {
flex-basis: 70%;
}
.newsletter {
background: #ccc;
}
.newsletter__inner {
margin: 0 auto;
max-width: 1200px;
}
.hero-banner {
background: linen;
}
.hero-banner__inner {
margin: 0 auto;
max-width: 1200px;
}
.call-to-action {
background: #f1f1f1;
}
.call-to-action__inner {
margin: 0 auto;
max-width: 1200px;
}
SCSS Mixin
Compiled Output
Does following Helix for FE end in a bloated application?
Is this more acceptable for BE where we don't have to worry about page weight & speed
Is this alien to a lot of FE devs?
Sitecore can be a lot to take in - by enforcing Helix are we steepening the learning curve?
Are we (BE) guilty of dictating to FE?