Design Systems and Component Based Frontend

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