Décomposition de projet pour frontend

Parlons de ce que vous savez déjà.

Ceci est mon premier article sur Habré et je ne suis pas écrivain. Mais en regardant Frontend 2018: les résultats de l'année , les mains se sont sublimées et ont commencé à écrire.

Toute tâche difficile consiste en des tâches simples. La capacité de faire la décomposition correctement est un must .

Je dirigerai la discussion sur l'exemple de la plupart des projets par expérience personnelle.

Je suis sûr que vous direz: " Mais nous ne l'avons pas du tout et réagissons est rapide, logique et lisible, générer des styles à l'aide de js n'est pas une sorte de module complémentaire, c'est à la mode, mais les développeurs frontaux ne sont pas nécessaires, car notre fournisseur back-end Feofan a fait une excellente forme en php "mais quand même.

Désignation
G1. Les génies qui peuvent, sont des exceptions, un cas magnifique spécial.
M *. La pensée

Cela ne peut pas être lu

Commençons donc!

M1. Le doublage de code est mauvais.

M2. Vous devez toujours penser à 100 pas en avant.

Par exemple, au démarrage d'un projet, nous prenons en compte son état après 5 ans.

Évidemment, en démarrant un réseau social, on peut immédiatement dire qu'en plus de la version web il y aura des applications mobiles, des applications de bureau. D'ici ...

M3. La partie serveur ne doit être écrite qu'une seule fois. (M1)

Et puisque nous avons une version web, mobile, desktop, alors ...

M4. Le côté serveur traite des données.

Le côté serveur ne doit pas décider quel bouton dessiner et quelle couleur il doit être.

Un modèle de lettre ou un fichier html qui [peut] est chargé lorsqu'une page est chargée pour indexation par un moteur de recherche fonctionne également avec les données. Hélas, vous devez y manipuler du HTML (en raison d'exigences d'indexation, par exemple), mais c'est un autre problème.

En fait, on pourrait transférer l'ensemble initial de fichiers (html, js, css) et de données. C'est-à-dire et ici le dos n'est pas impliqué dans la mise en page.

Ici, la première panne du projet s'est produite: la partie serveur s'est interrompue. Je ne discuterai pas dans quelle langue il est écrit, comment l'architecture est arrangée (je me souviens bien de MVC). Ce n'est pas mon affaire pour ...

M5. Chacun doit faire son propre truc.

Des piles complètes couvrent certains des projets, et ici vous pouvez et vous argumenterez certainement sur ce point, mais en faisant référence à (M2), ma position ici est formée: il est moins cher d'avoir deux professionnels dans votre domaine que de réécrire le projet en un an. Bien sûr, il y a des génies (G1) qui suivent partout, mais il y a de telles unités, ce qui signifie que vous ne pouvez pas les prendre dans les arguments "Comme il se doit".

Je vais également retirer de cette tarte une branche de Designer, Ergonomie et co.

Comprenez bien, un fournisseur frontal normal peut déployer indépendamment un jalon, en se concentrant sur un million d'analogues et son imagination, mais nous parlons de projets sérieux selon (M2), alors ne vous flattez pas :) (G1)

Eh bien, nous avons des données (api, toutes les méthodes nécessaires, etc., etc.), nous avons des mises en page - et commençons.

Compte tenu des réalités modernes - je voudrais introduire une autre branche. Hélas, mais une énorme proportion de fournisseurs frontaux modernes ne savent pas comment travailler avec la mise en page, ou ne connaissent pas js. J'ai mené un grand nombre d'entretiens et c'est étrange à observer. Par conséquent, les façades peuvent être divisées en «concepteurs de mise en page» et «concepteurs non agencés ??».

M6. Le développement doit être dans plus d'un fichier

Dites-moi, évidemment? Oui, évidemment!

M7. La face avant est divisée en 2 parties: celle qui fonctionne avec les données et celle qui les affiche.

Nous pouvons ne pas avoir telle ou telle partie. Par exemple: être uniquement affiché (page statique) ou être uniquement des données (script dans la console, etc.).

Ici, je suggère de résumer et de présenter: vous êtes une pizzeria. Vous recevez des appels, disposez le fromage à merveille et apportez-le à l'acheteur. La logique suggère que vous n'êtes pas particulièrement efficace (M1). Mais si 2 autres personnes travaillaient avec vous, ce serait beaucoup plus cool! L'un reçoit des appels (travaille avec des données), le second reprend (présentation), le troisième dispose magnifiquement le fromage :) (stylisation de la présentation)

Déjà j'entends "CEP" de 2012, "évidemment", mais encore une fois ...

M8. JS travaille avec des données.

Il appelle le backend, accepte la commande et peu importe comment le fromage y est déposé. Peut-être que la pizza n'existe pas du tout, peut-être qu'il fait juste une enquête sur la pizza de l'année?

M9. Représentation HTML

Montre la pizza au client, accepte également les commentaires (argent, avis) et les transmet à l'administrateur (JS).

M10. CSS - style de présentation

Retrait entre les deux tranches de fromage.

Notez que l'administrateur au téléphone ne dit pas comment empiler le fromage et que la pizza ne contient pas de personne parlant au téléphone. Toute tentative de manipulation de styles à l'aide de js ou de manipulation de js à l'aide de html est initialement un complément, elle est initialement mauvaise. Les classes et la gestion d'événements ont été inventées pour une raison.

Vous pouvez mettre une classe: pepperoni, salami, mais il n'est pas de votre compétence de décider comment déposer le fromage pepperoni.

Vous pouvez mettre bas bind: si vous avez été botté, n'a pas payé, dites à l'administrateur. Mais ne bousculez pas l'administrateur en pizza. Il est seul et il y a beaucoup de pizzas! Si vous avez autant de pizzas que d'opérateurs, alors M1.

Et donc, dont js, css, html sont responsables - nous l'avons compris.

Vous pouvez désormais poser des questions entières: comment cuisiner une pizza, comment la livrer plus rapidement et plus facilement, et comment parler aux clients par téléphone.

Je veux en quelque sorte définir le mot désormais à la mode " Composant ". En fait, même un bouton standard est déjà un «composant», mais je vais le redéfinir avec des exemples évidents. Un bouton est un bouton et un composant:

1. Aperçu de la publication
2. Commentaire
3. Aperçu du fichier
4. Voter sur le habr
5. Le bloc "postes vacants"
6. Texte html de l'article, des critiques, du webinaire
etc.

M11. Un composant doit avoir la même apparence partout.

Partout où vous publiez un aperçu de la publication, sur quelle page vous l'ouvrez, elle devrait avoir la même apparence. La règle des trois couleurs. Tout doit être reconnaissable par l'utilisateur.

Modifications - changements forcés, si nécessaire. Fabriqué en CSS.

Ou est-ce un autre composant

(Par exemple, l'aperçu de la publication dans la colonne de droite peut différer de l'aperçu de la publication au bas de la page).

M12. Le composant est composé de [html], [js], [css].

Chacune des pièces est facultative.

M13. Quel que soit le nombre d'instances d'un même composant, ses styles ne doivent être enregistrés qu'une seule fois

Par exemple, l'aperçu du post à droite, l'aperçu du post ci-dessous, l'aperçu du post dans la notification et les styles ne sont enregistrés qu'une seule fois.

M14. Seule la base doit être enregistrée dans le composant js

Par exemple, les gestionnaires d'événements en cliquant sur les boutons, les données nécessaires à l'affichage. Tout le reste doit être rendu.

M15. Un composant peut être composé de composants

Par exemple, une liste de publications.

M16. Styles extraits dans un fichier séparé

Ces fichiers sont mis en cache, de plus, il n'y aura pas de tentation de les écrire en ligne, ce qui signifie de les dupliquer.

M17. Les styles de composants doivent se lier via les classes parentes et uniquement

La page de n'importe quel site est comme beaucoup de boîtes de différentes tailles, qui sont comme des poupées gigognes imbriquées les unes dans les autres.

Une boîte est un composant.

Vous avez une boîte avec des boîtes et des articles. Vous n'avez jamais besoin de réfléchir à la façon de décrire l'intérieur d'une boîte imbriquée. Décrivez seulement cela.

Ici, ils ont inventé un tas de vélos, mais messieurs, il n'y aura aucun problème avec les noms, dès que vous déterminez vous-même l'ensemble des composants. Si vous ouvrez VKontakte et y comptez le nombre de composants, eh bien, vous comptez 30 pièces. (Ne comptez pas sur Facebook, il n'y a que de la douleur).

Vous ne pouvez pas trouver 30 noms de classe? Et à juste titre, il n'y a rien à proposer:

M18. D'autres personnes liront votre code.

Donc le nom naturel est le meilleur nom

Par exemple

1. liste des articles
2. liste de commentaires
3. liste de nouvelles
4. après la prévisualisation
5. commentaire-aperçu
6. aperçu des nouvelles
7. post-détail
8. commentaire-détail
9. détail des nouvelles

Incroyablement difficile, hein? Et l'essentiel est incompréhensible et difficile à maintenir

Et à propos de la «lecture d'autres personnes», désabonnez-vous également:

M19. Html, js, css doivent être stockés séparément!

Si vous devez les combiner ensemble, trouvez une solution différente que de les écrire dans un seul fichier. React est le plus dégoûtant en termes de lisibilité que j'ai vu!

La page sur les «Boîtes» était divisée, comment stocker les fichiers - discutée. Quoi d'autre?

M20. Il n'y a presque pas de cas particuliers

Et si cela se produit, alors demain vos managers viendront au travail et diront "qu'il faut modifier l'implémentation à la demande du client". Résolvez les tâches aussi largement que possible.

Par exemple, dans notre travail, nous, quel que soit le projet, séparons immédiatement certaines tâches: calendriers, formulaires de saisie, fenêtres contextuelles, menus de différents remplissages, affichage de fichiers et autres widgets qui interagissent avec l'utilisateur. Pour ainsi dire, "fonctions de caractère"

M21. L'écriture de style nécessite une décomposition

Le monde ne nous a pas seulement donné le merveilleux MOINS, SASS.

Votre projet a un ensemble fixe de polices, couleurs, ombres, presque tous les projets sérieux ont des schémas de couleurs, donc lors de l'écriture de styles, tout cela est paramétré. Et ici, ce qui suit est important

M22. Si vous souhaitez modifier la couleur de la police (etc.), vous ne devez effectuer des modifications qu'au même endroit

En conclusion, je voudrais mentionner un problème important.

M23. Une formulation correcte du problème conduit à la bonne solution.

Peut-être alors qu'il n'y aurait pas de css-in-js, facebook et quelque chose qui ne devrait pas être appelé.

Passez une bonne journée à tous!