README
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
, Card
s, Slider
s, 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\\:")
.
@acanto/frontend
Note per lo sviluppo di progetti con 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 pathfrontend/vendor/gsap-bonus.tgz
- nelle
dependencies
delpackage.json
del progetto in corso aggiungere questa voce con il path giusto:
"dependencies": {
...
"gsap": "file:frontend/vendor/gsap-bonus.tgz"
}
- lanciare
npm install
onpm 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 installnpm install -g linklocal
thencd into-your-project
and runlinklocal -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
- use new
Documentazione
- Aggiungere descrizione del modulo visibile quando fai hover sull import
/// <reference path='./index.d.ts' />