Design Systems and Component Based Frontend

Design Systems and Component Based Frontend

80d92d5d0bd0170aebf6e07589a0b571?s=128

Bilal Çınarlı

June 27, 2019
Tweet

Transcript

  1. Design Systems & Component Based Frontend

  2. Bilal Çınarlı Frontend Architect Software Engineer @Adidas @bcinarli github.com/bcinarli bcinarli.com

  3. None
  4. Harmony from Intuit, GEL – Global Experience Language from BBC,

    Material from Google, Lightning from Salesforce, AirBNB’s Visual Language, Joystick from EA, Fluent from Microsoft, Plasma from WeWork, Polaris from Shopify, Lonely Planet, Swarm from Meetup, Canvas from Hubspot …and aDL from Adidas
  5. What is a design system?

  6. A collection of reusable components, guided by clear standards, that

    can be assembled together to build any number of applications.
  7. None
  8. A design system is a combination of style, components, and

    voice.
  9. It is scalable at any level

  10. Provides consistency between different pages and applications

  11. With the set of rules and guides, increases the efficiency

  12. Enhances the teamwork and eases the on-boarding of new members

  13. http://bit.do/yarnds

  14. http://bit.do/adl_

  15. Components

  16. Components support levels of abstraction in an application. It is

    layered and feature-based.
  17. Individual components provide decoupling which leads to better unit testings

    and stability.
  18. Design system and Components combine mostly in UI layer where

    your presentation occurs
  19. Besides, components can also communicate with the data layer while

    rendering our content.
  20. …and with the standardisation, it improves quality.

  21. None
  22. How Popular Libraries Think?

  23. Build encapsulated components that manage their own state, then compose

    them to make complex UIs.
  24. Components define areas of responsibility in your UI that let

    you reuse these sets of UI functionality.
  25. It’s an abstraction that allows us to build large-scale applications

    composed of small, self-contained, and often reusable components.
  26. But the mainly, they should have a responsibility over a

    single part.
  27. None
  28. How to Organise?

  29. Define your folder structure based on their functionalities

  30. Think of everything is sort-of a pluggable component. In most

    cases, when you remove it, you should expect no traces left.
  31. // DON’T . !"" controllers | !"" cart.js | #""

    checkout.js !"" models | !"" cart.js | #"" checkout.js #"" views !"" cart.pug #"" checkout.pug // DO . !"" cart | !"" index.js | #"" template.pug #"" checkout !"" index.js #"" template.pug
  32. …and tests are a part of your components.

  33. // add test specs . !"" cart | !"" index.js

    | !"" test.spec.js | #"" template.pug #"" checkout !"" index.js !"" test.spec.js #"" template.pug
  34. Separate config and scripts away from your components.

  35. . !"" config | !"" index.js | #"" server.js !""

    scripts | !"" build.sh | #"" post-install.sh !"" test | !"" index.js | #"" setup.spec.js !"" cart | !"" index.js | !"" test.spec.js | #"" template.pug #"" checkout !"" index.js !"" test.spec.js #"" template.pug
  36. Keep HTML and CSS separate in your source code and

    never inline manually
  37. // DON’T <p style="margin: 10px 0; padding: 0;">Hello World! </p>

    // DO .content-text { margin: 10px 0; padding: 0; } <p class="content- text">Hello World!</p>
  38. Always think about specificity in CSS, try to avoid creating

    specific selectors
  39. // DON’T #main .article .title span { font-size: 32px; font-weight:

    bold; } // DO .main-article-title { font-size: 32px; font-weight: bold; }
  40. Do not write the code you are going to overwrite

  41. // DON’T .content { display: flex; max-width: 1280px; margin: 0

    auto; } .article { width: 900px; } .supplementary { width: 380px; } @media screen and (min-width: 48.0625em) and (max-width: 64em) { .article { width: 644px; } } @media screen and (max-width: 48em) { .content { flex-direction: column; } .article, .supplementary { width: 100%; } } // DO .content { max-width: 1280px; margin: 0 auto; } @media screen and (min-width: 48.0625em) { .content { display: flex; } .article { flex: 1; } .supplementary { width: 380px; } }
  42. A way to unify different frameworks?

  43. Web components are a set of web platform APIs that

    allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps.
  44. Custom components and widgets build on the Web Component standards,

    will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.
  45. <script type="module" src=“components/nav/app- drawer“></script> <app-drawer raised class=“indigo">raised</app-drawer>

  46. <script> class AppDrawer extends HTMLElement {...} window.customElements.define('app-drawer', AppDrawer); </script> <app-drawer></app-drawer>

  47. Good part, all JS frameworks outputs to HTML. Theoretically, we

    can use any popular JS library to create Web Components
  48. What is more?

  49. Having self-contained, reusable components helps to turn you app to

    micro frontends
  50. … that can have independent deployment, build, coding

  51. … leads to autonomous teams

  52. … and you can have a shell that orchestrates which

    micro frontend to load
  53. … with the “Best Friend of Frontend"

  54. Your components should not know what the dependencies are in

    behind the curtains you are using.
  55. It should only aware of which functions are available for

    a particular action.
  56. Every dependency comes with a technical debt for the future.

  57. Thank you @bcinarli