Dev front-end

Fondamentaux

Le Front-end

On parle de développement Front-end pour désigner des applications clientes, c'est à dire qui sont exécutées sur la machine de l'utilisateur.
Par opposition, le développement Back-end fait référence aux applications qui sont exécutées sur des serveurs distants.

On parle parfois de client léger ou de client lourd.
- Le client léger est une application qui fonctionne via un navigateur.
- Le client lourd est une application qui fonctionne via le système d'exploitation.
- Malgré leur nom, les clients lourds sont généralement plus performants du fait de leur code natif mieux optimisé
- On pourra préférer les appeler applications natives (native apps) et applications web (web apps).
Le Front-end peut faire référence à ces 2 types d'applications, mais le développement Front-end désigne très généralement le développement d'applications web.

HTML - CSS - JS

Il n'y a pas de différence technique entre un site web et une application web.
La seule différence est celle du propos : une application rends un service, une site web apporte de l'information.
La frontière est souvent floue et n'a pas d'importance pour le développement.

index.html


                <html>
                    <head>
                        <title>Ma Page</title>
                    
                        
                    </head>
                    <body>
                        <div>Le contenu de ma page</div>

                    
                        <script type="text/javascript" src="main.js"></script>

                    
                        <script type="text/javascript">
                            // ici mon code javascript
                        </script>
                    </body>
                </html>

index.html est par convention la première page chargée lorsqu'aucun document n'est précisé.
Par convention, on appellera notre fichier JS principal "main.js" ou "app.js".
On pourra le ranger dans un sous dossier relativement à la page html.
Par convention, on appeller notre fichier CSS principal "styles.css".
On pourra le ranger dans un sous dossier relativement à la page html.
On utilise des chemins relatifs pour rattacher les fichiers entre eux.
- href="css/styles.css" pour accéder à styles.css depuis index.html
- src="js/main.js" pour accéder à main.js depuis index.html
- background-image: url(../images/header.jpg) pour accéder à une image depuis styles.css

Arborescence finale :


                        
                            projet/index.html
                            projet/js/main.js
                            projet/css/styles.css
                            projet/images/<fichiers images>

Point de vue du navigateur web

Le HTML est transformé en DOM
Le DOM est un arbre, c'est à dire un objet qui contient des sous objets, et qui décrit ce que le navigateur doit afficher
Le DOM contient 100% des infos dont le navigateur a besoin pour calculer le rendu
Le DOM peut être modifié en JavaScript (et on ne va pas se priver !)
Un arbre contient des nœuds, chaque nœud a un parent (sauf le nœud racine). Chaque balise html sera transformée en nœud dans le DOM, on pourra ensuite accéder à son nœud parent (la balise englobante), et à ses enfants (les balises englobées).

Compatibilité

Support des navigateurs

https://caniuse.com/

Compatibilité : Modernizr

Détecte le support d'une fonctionnalité par le navigateur

https://modernizr.com/

Au moment d'afficher la page chez l'utilisateur, répond à la question : Le navigateur supporte t'il la fonctionnalité X ?
Pivot de l'amélioration progressive (progressive enhancement)
Plus fin que la détection de user-agent navigateur

Compatibilité : Polyfills

Ajoute en JavaScript une fonctionnalité native qu'un navigateur n'implémente pas


                🔎 <nom_fonctionalité> polyfill <navigateur_cible>

Compatibilité : BabelJS

Permet de faire fonctionner une version récente de javascript (ES6) sur un navigateur qui ne le supporte.

https://babeljs.io/

Quelques mots clés

Bibliothèque (Library) : A utiliser en l'état
Framework : Impose une manière de faire
Boilerplate : Squelette d'application pré construit
Generators : initialise une appli sur mesure

Architecture orientée composants

Approche traditionnelle : progressive enhancement (amélioration progressive). On part d'une page web 100 % HTML et CSS, des scripts JavaScript viennent enrichir le comportement du HTML en se branchant sur l'existant. Dans l'idée, le site internet devrait être entièrement fonctionnel sans JavaScript.

Approche composant : plutôt que de découper l'application en technologies et en couches, on la découpe en composants. Chaque composant est lui même une sous-application de l'application, il rassemble au même endroit des données, des informations de rendu (HTML, CSS), et des comportements (JS). Il peut lui même contenir des sous-composants.

La communication naturelle entre composants est descendante : un composant parent envoi une information au composant enfant en lui passant une props

La communication transverse est possible via JavaScript. Différentes techniques existent : entrepôt de données (store), Système d'événement global, Contextes (React).

La communication ascendante est possible, cependant le parent doit donner une opportunité de réponse au composant enfant (fonction de rappel ou callback)

Conception réactive

Pourquoi React et autres frameworks sont-ils populaires ? En grande partie grace à leur mode de conception "déclaratif" ou "reactif".

En effet, l'architecture orientée composée tel que le propose React permet de déclarer l'affichage tel qu'on le veut en fonction des données. rendu = fonction(props, stats). Cette forme de conception s'oppose à la programmation impérative qui décrit des suites de transformations. Ici on change la donnée, et le framwork se charge de transformer le rendu automatiquement pour correspondre à la nouvelle description.

Composants

Un composant est une brique applicative autonome vis à vis de son rendu et de son interactibilité.
Par convention, son nom commencera toujours par une majuscule. Il est fréquent d'utiliser une majuscule pour le nom de fichier également
Il peut lire des données lui venant de son parent (this.props)
Il peut lire des données statiques immuables (constantes internes ou importées)
Il peut lire et écrire dans un état interne propre (this.state) qu'il utilisera pour le rendu de données dynamiques transverses (ex: retour d'événément click)
La modification du state doit se faire explicitement en React: this.setState({myKey: 'data') et ne dois jamais être faite dans la fonction de rendu
Doc React sur les composants Doc React sur les cycles de vie

Préférer l'utilisation de composants contrôlés, plus faciles à intégrer dans une logique déclarative.

Routage

Router consiste à faire correspondre une URL à une "page".
Dans une application web, la notion de "page" est parfois floue voire inexistante. Dans le cas, le routage fera référence à l'association entre une URL et un état spécifique de l'application.
L'association URL / page est à définir ensemble entre le développeur et le responsable du produit.

Router revient donc à :
- Lorsqu'on arrive sur la page,
  => mettre l'application dans un état prenant en compte les paramètres d'ur
- Lors d'une action de navigation qui ne recharge pas la page,
  => mettre à jour l'url et mettre l'application dans un état prenant en compte les paramètres d'url
- Si application web (SPA): indiquer au serveur que toutes les URL doivent redirifer vers le même point d'entrée.
Pour écouter un changement d'url :
- Au chargement de la page: dans un script exécuté dès le chargement
- Lors d'une action de navigation interne: window.addEventListener("popstate", event => {})
Pour manipuler l'url: history.pushState(null, event.target.pathname, event.target.pathname)

Exemple sur Github

Architecture applicative

App
- Components => app agnostic
  - MyComponent
- MyLayoutComponent => app specific
  - MyLayoutSpecificComponent => can use MyComponent