Acanto Frontend

Libreria di strumenti, utility, componenti e altro per lo sviluppo frontend dei siti di Acanto @acanto/frontend.

L'idea è quella di avere piccoli componenti facilmente riutilizzabili senza dover sovrascrivere comportamenti CSS o JS nei singoli progetti. Tutto ciò che include questa libreria deve quindi essere scarno e generico e buttar fuori il minor codice possibile.

Quando utilizzi questa libreria è bene quindi selezionare con cura i vari componenti e parti di componenti che si vogliono includere nel progetto in corso.

Struttura

Styles

Tutta la parte di CSS è scritta in SCSS prediligendo mixin e placeholder di modo che anche se inclusi non generino codice fino al loro utilizzo esplicito.

Scripts

Il JavaScript di questa libreria deve rimanere in codice nativo, senza framework o librerie troppo complesse. Nel momento in cui queste sono necessarie l'importante è scrivere la libreria di modo che il tree shaking elimini la possibilità di inclusione involontaria di librerie e grossi blocchi di codice inutili.

Templates

I componenti che hanno bisogno di un template da usare in October usano qui un file .twig (o .php se necessario) d'esempio in quanto non possono essere integrati in maniera automatica nel progetto all'interno del CMS. Sarà quindi necessario copiare/incollare/modificare a piacimento il template nella cartella /frontend/components/ o /frontend/core (quest'ultimi possono essere sincronizzati in quest'ultima tramite @acanto/workflow con il comando acanto core-sync). About composing .twig components with nested children see the solution suggested on SO

Code conventions

Class names

core

Core elements are very generic and of common use case. They are usually used repeatedly in the same page and across the same website. Their flexibility should allow to use them even without alteration across different projects. They should be in fact responsible of basic and common elements and UI like forms, images, buttons, typography, ecc. Their class naming follows this pattern:

.myClass
.myClassInner
.myClass--modifier

components

Components are quite specific pieces of UI that are usually reused within the same project and can, but not necessarily need, to be reused accross different projects. They should be responsible of specific functionalities and should be configurable from outside enought to allow their reuse in the same project. Usual use cases for components are pieces of UI like the Header, the Footer, Cards, Sliders, ecc. Their class naming follows this pattern:

.Mycomponent:
.Mycomponent:block
.Mycomponent:block--modifier
.Mycomponent:block__element
.Mycomponent:block__elementInner
.Mycomponent:block__element--modifier

routes

Routes contain code that is always scoped and outputted only to its specific template. So by default JS and SCSS code written here cannot interfere with other routes/pages. It's often handy to divide a page in sections and namespace them to organize the code. Sections of a page often look like .intro:, .details:, .products:, .featured:, etc. Their class naming follows this pattern:

.pagesection:
.pagesection:block
.pagesection:block--modifier
.pagesection:block__element
.pagesection:block__elementInner
.pagesection:block__element--modifier

Notes

Class names for state and behaviour

Class names that denote states or behaviour are shorter and descriptive like:

.is-visible
.has-link
.has-img
.is-doubled
.is-even
.when-vertical
etc.

Regarding the use of column :

In SCSS the : needs to be escaped by a backslash as such Mycomponent\:, while in JS using the $ or $ or escape functions to deal with DOM selectors the column : is automatically escaped. Otherwise it needs to be escaped as such querySelector(".Mycomponent\\:").

Note per lo sviluppo di progetti con @acanto/frontend

GSAP

Per usare GSAP premium inanzitutto scaricare lo zip GSAP with Shockingly Green bonus dalla dashboard di greensock.com

• scompattare lo zip, trovare e copiare il file gsap-bonus.tgz così com'è nel progetto in corso. Possibilmente copiarlo nel path frontend/vendor/gsap-bonus.tgz
• nelle dependencies del package.json del progetto in corso aggiungere questa voce con il path giusto:

"dependencies": {
  ...
  "gsap": "file:frontend/vendor/gsap-bonus.tgz"
}

• lanciare npm install o npm i
• nel file JavaScript dove si intende usarlo fare un normale import e registrare i plugin che si vuole utilizzare per evitare problemi di tree shaking nella futura build di production. Ad esempio:

import gsap from "gsap";
import CSSPlugin from "gsap/CSSPlugin";
import SplitText from "gsap/SplitText";

gsap.registerPlugin(CSSPlugin, SplitText);

• a posto.

Da notare è che il file frontend/vendor/gsap-bonus.tgz deve rimanere nel repository e su git altrimenti la CI non sa dove andarlo a prendere non essendo pubblica questa libreria.

Note riguardo allo sviluppo interno di questa libreria

• To develop and use the library locally (through npm link) and get the Intellisense of VScode to work first install npm install -g linklocal then cd into-your-project and run linklocal -r, see related issue
• About tree shacking, sideEffects and unused modules see webpack's side-effects, harmony-unused and see this issue with css imports
• About GreenShock premium plugin being on npm, see this thread
• We might use SimpleStateManager to use media queries in javascript, populating its states with the exported sass variables.
• Parallax scrolling well done with CSS variables basicScroll or Rellax
• For masonry like grid infiniteGrid seems ok.
• For simple SSR components abstraction see gia
• For SPA like behaviour try Stimulus with Turbolinks
• TODO:
  • use new isType functions where appropriate
  • Maybe use https://www.npmjs.com/package/throttle-debounce instead of lodash ones
  • Incorporate autocomplete in library as abstraction

Documentazione

• Aggiungere descrizione del modulo visibile quando fai hover sull import /// <reference path='./index.d.ts' />