Norse Polytheistic Mythology
    Have ideas to improve npm?Join in the discussion! »

    @acanto/frontend

    5.1.2 • Public • Published

    Acanto Frontend

    npm (scoped)

    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

    Documentazione

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

    Keywords

    none

    Install

    npm i @acanto/frontend

    DownloadsWeekly Downloads

    91

    Version

    5.1.2

    License

    ISC

    Unpacked Size

    707 kB

    Total Files

    430

    Last publish

    Collaborators

    • avatar
    • avatar