J'ai construit cette application dans le cadre d'un défi de codage pour une position de développeur Frontend avec une startup au centre-ville d'Austin. Cette application est une calculatrice simple utilisant Preact, CSS-Grid et Flexbox.
démarrage rapide
concepts de conception
technologie utilisée
Processus de test et de construction
Pour tester ou afficher cette application sur votre machine locale, clonez ce référentiel. Accédez à votre référentiel nouvellement cloné et exécutez les commandes suivantes:
yarnOu alternativement pour l'utilisateur NPM:
npm installPuis courez:
yarn startOu alternativement pour les utilisateurs de NPM:
npm startAccédez à http: // localhost: 8080 / et amusez-vous!
Aucune spécification de conception n'a été fournie pour ce défi. On m'a donné un règne libre à la conception comme je le faisais. En gardant à l'esprit l'emploi pour lequel je postulais, j'ai choisi de répondre à mon produit au client. En tant que tels, la palette de couleurs, la palette et même le favicon sont intentionnellement similaires à leur page d'accueil. (L'idée étant que le client a déjà affiché une préférence pour ce schéma de conception car il a choisi exactement la même conception pour son site Web de production. Il affiche également une attention aux détails.)
Voici des photos à comparaison.
Site Web original 
Application de calculatrice 
J'ai utilisé ce défi de codage comme une opportunité de jouer avec la nouvelle grille CSS native (quelque chose que je voulais faire depuis un certain temps). La grille CSS est incroyable, mais apparemment, il est presque impossible de passer des propriétés de la région de grille comme accessoires.
J'ai également utilisé Flexbox pour centrer le contenu et les éléments. Je suis un grand fan de Flexbox et je le préfère fortement aux autres solutions de grille tiers ou à l'utilisation de flotteurs pour le positionnement des éléments.
Cette application est également probablement la première fois que j'ai un cas d'utilisation justifiable pour la fonction CALC ()! J'utilise calc () pour définir la hauteur de la page principale égale à 100 VH moins la hauteur de la barre d'en-tête et un décalage inférieur pour garantir que les éléments ne se chevauchent pas.
Tout au long du processus de conception, j'ai tenté d'adhérer à certains principes de conception de l'interface utilisateur de base comme indiqué ici https://medium.com/@erikdkennedy/7-Rules-for-Creating-Gorgeous-Ui-part-1-559d4e805cda
Cette application utilise:
Grille native CSS
Flexion
Prédiction
Préact-routeur
CLI Preact
Moka
Chai
Eslint
La grille native CSS est assez impressionnante, bien que le support du navigateur puisse manquer de navigateurs plus âgés. Il est apparemment incroyablement difficile de passer les styles CSS comme accessoires à d'autres composants imbriqués. Surtout lorsque chaque composant enfant nécessite un attribut de position unique pour travailler avec la grille native CSS. Évaluation des accessoires de type de chaîne dans une référence pour le style de classe CSS échoue. Même lorsque vous utilisez des exemples directement hors de la documentation Preact. CSS-Grid n'accepte pas les chaînes comme des arguments sur la zone de grille. Mon programme ne peut pas discerner entre une référence CSS VAR et une référence JS.
Flexbox est incroyable et a un meilleur support de navigateur que le réseau natif CSS. Il ne faut plus dire à ce sujet.
Preact est une technologie intéressante. J'aime qu'il soit léger, j'aime aussi sa fonctionnalité rapide et que c'est un match presque parfait pour React mais avec une licence MIT. J'ai l'impression que certains des outils de construction font défaut par rapport à l'écosystème React.
Preact-Router dans cette application n'est qu'une configuration minimaliste. Je ne l'ai pas suffisamment traité pour en parler en profondeur.
La configuration de Preact CLI échoue hors de la boîte sur leur manque de commande de test et une configuration Eslint mal configurée (ou un code écrit par eux qui viole leurs propres règles de validation). La configuration des tests fait défaut et j'ai dû configurer la mienne (plus à ce sujet plus tard). Pour tout système de construction, la configuration de l'utilisation du karma est à peu près obligatoire de ce que je recueille. Leur commande de construction échoue également.
J'utilise Mocha et Chai pour ma configuration de suite de test. C'est un classique testé dans le temps.
Eslint a été inclus hors de la boîte (défaillant, sera couvert plus en détail plus tard).
Toute la logique d'application dans le composant de la calculatrice. Tous les autres sont des composants purs / fonctionnels. Si j'avais besoin de créer une application plus complexe, MOBX ou Redux auraient été en ordre.
MOBX ou Redux aurait également aidé aux tests de fonction. J'ai d'abord tenté de découpler la logique de la composante, mais il est difficile de préserver le contexte de «ceci» en ce qui concerne la logique qui modifie l'état. J'ai donc choisi d'écrire directement la logique dans le composant. L'importation de méthodes qui nécessitent une sensibilisation à l'État à partir d'un fichier séparé sans un contexte d'état complique inutilement les choses (c'est de toute façon exagéré car nous n'avons que quelques méthodes dans cette application).
Sur le sujet de l'État, le JavaScript EVAL () n'acceptera pas un opérande non corpore. Il gérera très bien les entiers, mais débote un opérand et vous aidez donc à Dieu que votre application est condamnée! Je gère toutes les données critiques de calcul dans l'état en tant que chaîne pour m'assurer que cela ne se produit pas.
Sur une note aléatoire, cette application exécute à partir de localhost scores plus haut sur l'évaluation Lightbox dans les 4 catégories de PWA, de performances, d'accessibilité et de meilleures pratiques par rapport au site Web actuel de la production actuel.
J'ai tenté de conserver des dépendances supplémentaires au minimum pendant le développement des applications.
La suite de test peut être exécutée avec yarn test ou npm test . La suite de tests suppose une installation mondiale de moka sur votre machine.
La bibliothèque Preact elle-même a des problèmes ouverts liés aux tests = préactjs / préact # 658 Leur solution de contournement consiste à utiliser une bibliothèque peu connue appelée https://github.com/developit/preact-jsx-chai/, malheureusement, cette bibliothèque n'a pas semblé fonctionner pour moi.
La configuration de test est une douleur. Les configurations Babel sont cachées par préact-Cil. Impossible d'accéder à la configuration. Obtenir "l'importation de jetons inattendu" même lorsque je place le fichier de test dans le même dison que le composant lui-même. " Les tests devront attendre. Refait encore, je devrais implémenter une autre alternative pour permettre des tests de fonction séparés.
Sur le sujet des tests, voici une tonne de problèmes qui y sont liés:
Preactjs / Preact-Compat # 233
Preactjs / Preact # 146
https://gist.
PREACTJS / PREACT # 658 (problème ouvert, la configuration du test préact difficile est un problème connu sans solution actuelle.)
PreactJS / Preact # 560 (aborde la façon dont le préact est opiniâtre et nécessite le karma comme une autre dépendance.)
https://gist.
https://preactjs.com/guide/unit-testing-with-enzyme (leur documentation est littéralement une section. Et n'offre aucune alternative à leur configuration exacte de karma.)
Et en libin, l'Eslint échoue à l'extérieur de la boîte. J'entente en utilisant 4 espaces. Le plugin par défaut de PREACT ESLINT est défini sur les onglets, ce qui entraîne le lancement d'erreurs. Quoi qu'il en soit, la configuration des tests s'exécute et est en place pour brancher toute configuration de configuration Eslint. Je serais en mesure de reconfigurer instantanément cette configuration pour correspondre à tous les exigences spécifiques au client.