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
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.
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.
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.
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