$30 off During Our Annual Pro Sale. View Details »

Components on the Web: Frontend NE

Components on the Web: Frontend NE

Jack Franklin

April 05, 2018

More Decks by Jack Franklin

Other Decks in Technology


  1. @Jack_Franklin 1

  2. @Jack_Franklin 2

  3. A component is a self contained element made up of

    HTML, CSS and JavaScript. We can combine lots of components together to create user interfaces. @Jack_Franklin 3
  4. The plan 1. The road to components ! 2. The

    theory of components " 3. The approaches and challenges of building good components ✅ 4. How to introduce components to your project/ product/app/site $ @Jack_Franklin 4
  5. All of today's talk is reasonably new, especially within the

    context of front-end development @Jack_Franklin 5
  6. Today I'm going to talk you through some of my

    experiences, but I'd love to hear yours! @Jack_Franklin 6
  7. The road to components When we didn't know any better,

    we stuck to patterns that had served us well on the server. @Jack_Franklin 7
  8. @Jack_Franklin 8

  9. @Jack_Franklin 9

  10. APIs and JSON /api/cat-pics [ { "id": 1, "name": "Fluffy",

    "age": 5 }, { "id": 2, "name": "Mittens", "age": 7 } ] @Jack_Franklin 10
  11. @Jack_Franklin 11

  12. @Jack_Franklin 12

  13. MVC doesn't fit frontend development @Jack_Franklin 13

  14. <p>This is a paragraph element (or...<em>component?</em>).</p> <h1>This is a heading</h1>

    <ul> <li>this is a list item</li> </ul> @Jack_Franklin 14
  15. And what if we could extend the box of bricks?

    1 <thread-user-avatar src="/img/jack.png"></thread-user-avatar> 1 https://developers.google.com/web/fundamentals/web-components/customelements @Jack_Franklin 15
  16. And what if we built frameworks around this idea, rather

    than the MVC approach? @Jack_Franklin 16
  17. The Theory @Jack_Franklin 17

  18. @Jack_Franklin 18

  19. A page is a series of components Made up of

    HTML, CSS and JavaScript 2 2 not necessarily all three @Jack_Franklin 19
  20. Pages will reuse the same components Common elements such as

    buttons, form inputs, user avatars, tweets, etc. @Jack_Franklin 20
  21. As it turns out, this approach works pretty well. @Jack_Franklin

  22. @Jack_Franklin 22

  23. The ideas in React are more important than React itself.

    And now exist in a plethora of front end frameworks. @Jack_Franklin 23
  24. I'm using React today because it's what I know best.

    —But this talk is not framework specific and can apply to any form of components. —Whether we're talking Angular, Ember, Vue, web components, or any other system. @Jack_Franklin 24
  25. Approaches and challenges of building good components ✅ @Jack_Franklin 25

  26. Components are designed to be a black box @Jack_Franklin 26

  27. "I want a carousel on my website" <jacks-custom-fancy-carousel speed="1000" infinite-playback>

    </jacks-custom-fancy-carousel> I don't need to care about how the carousel works in order to use it. @Jack_Franklin 27
  28. You should strive for "black box" components. @Jack_Franklin 28

  29. The "black box" approach enables working in isolation @Jack_Franklin 29

  30. @Jack_Franklin 30

  31. @Jack_Franklin 31

  32. @Jack_Franklin 32

  33. You can focus in on one component and one component

    only, without fear of breaking other parts of the site. You and your brain can focus in on the problem area and shut everything else out. @Jack_Franklin 33
  34. We keep all our component code in one folder, to

    help keep things isolated and to avoid directory jumping. @Jack_Franklin 34
  35. Avoid business logic @Jack_Franklin 35

  36. Your components should focus on presentations and interactions class SignUpToNewsletterForm

    extends Component { signUserUp() { // lots of // code here // to sign the user up // to your newsletter } render() { return ( <form> ... </form> ) } } @Jack_Franklin 36
  37. Pull any standalone logic out of your components so you

    can focus on the presentation. import { signUserUp } from '...' class SignUpToNewsletterForm extends Component { signUserUp() { signUserUp(...) } render() { return ( <form> ... </form> ) } } @Jack_Franklin 37
  38. You should keep your components reusable @Jack_Franklin 38

  39. Reusable components have to be configurable @Jack_Franklin 39

  40. ! Hey, please build me a component to view an

    item of clothing on Thread.com @Jack_Franklin 40
  41. class ThreadItem extends Component { render() { return ( <div>

    <ItemImage item={this.props.item} /> <h5>{this.props.item.title}</h5> <ItemPrice item={this.props.item} /> <ItemSentiment item={this.props.item} liked={this.props.item.liked === true} /> </div> ) } } @Jack_Franklin 41
  42. <ThreadItem item={...} /> ! Job done! " @Jack_Franklin 42

  43. Oh, can we make this page show ten different items?

    <ul> <li><ThreadItem item={...} /></li> <li><ThreadItem item={...} /></li> <li><ThreadItem item={...} /></li> <li><ThreadItem item={...} /></li> <li><ThreadItem item={...} /></li> </ul> ! Job done! " @Jack_Franklin 43
  44. OK but now can we make it so it shows

    the brand as well as the title <ThreadItem item={...} showBrand={true} /> ! Job done! " @Jack_Franklin 44
  45. Oh and also if it's on sale we want to

    show the old price alongside the new price <ThreadItem item={...} showBrand={true} showOldPriceBeforeSale={true} /> ! Job done! " @Jack_Franklin 45
  46. And we need to be able to not show the

    item sentiment sometimes <ThreadItem item={...} showBrand={true} showOldPriceBeforeSale={true} showSentiment={false} /> ! Job done... @Jack_Franklin 46
  47. For some items we want to show the brand instead

    of the name <ThreadItem item={...} showBrand={true} showBrandInsteadOfName={true} showOldPriceBeforeSale={true} showSentiment={false} /> ! Job done... @Jack_Franklin 47
  48. ! <ThreadItem item={...} showBrand={false} showBrandInsteadOfName={true} showOldPriceBeforeSale={true} showSentiment={false} /> Good luck

    understanding all these options in six months time... @Jack_Franklin 48
  49. @Jack_Franklin 49

  50. You will constantly play configurability off against maintainability. You as

    a developer and as a team will need to come up with a set of rules that suit you. @Jack_Franklin 50
  51. Optimise for developer readability @Jack_Franklin 51

  52. CSS @Jack_Franklin 52

  53. Every component should provide its styling. @Jack_Franklin 53

  54. @Jack_Franklin 54

  55. And none of them should conflict with each other. @Jack_Franklin

  56. Approaches to CSS —Class names per component —Enforced uniqueness via

    CSS Modules —CSS-in-JS @Jack_Franklin 56
  57. This is a big topic that I can only talk

    briefly about @Jack_Franklin 57
  58. Class names .jacks-carousel { } .jacks-carousel ul { } .jacks-carousel

    li { } /* and so on */ @Jack_Franklin 58
  59. All it takes is one slip... <!-- this is not

    a carousel but the styling is pretty similar and I'm under time pressure so I'll just use it anyway --> <div class="jacks-carousel"> @Jack_Franklin 59
  60. @Jack_Franklin 60

  61. 1. Define our CSS as normal. 2. Import our CSS

    (with a build tool like Webpack in the middle). 3. Use the classnames as generated at build time. @Jack_Franklin 61
  62. Class names are guaranteed to be unique. @Jack_Franklin 62

  63. CSS in JavaScript @Jack_Franklin 63

  64. const Button = styled.button` color: red; background: green; ` class

    TweetButton extends React.Component { render() { return ( <Button> New tweet! </Button> ) } } @Jack_Franklin 64
  65. https://javascriptplayground.com/introduction-to- styled-components-react/ @Jack_Franklin 65

  66. It's up to your team to decide what's best for

    you and your project There are many different solutions and many different libraries; experiment with a few and pick the ones that works best :) @Jack_Franklin 66
  67. When to break components down @Jack_Franklin 67

  68. Should this component actually be two? @Jack_Franklin 68

  69. Components are cheap, but not free —You pay in maintenance;

    more code and UI to maintain —You pay in complexity; another component that exists in your application —You pay in communication; this component will have to talk to others to get data @Jack_Franklin 69
  70. Components should be small, and you should have lots. @Jack_Franklin

  71. But how to know when a component is too big?

    —How many lines of code is it? —How many different HTML elements are there? —How hard is this file to understand? —Does the name have (or should have) an And in it? ItemNameAndPrice. @Jack_Franklin 71
  72. Allowing components to vary slightly ! @Jack_Franklin 72

  73. @Jack_Franklin 73

  74. Similarities Differences The icons Slight visual variations The like/dislike logic

    They are displayed next to each other Basically everything is the same but no the designer knows best 3 3 you should discuss if the variations make sense, but I guarantee you that they will at least some of the time @Jack_Franklin 74
  75. How do you have components that are 95% the same?

    @Jack_Franklin 75
  76. Explicitly allow component variants const SENTIMENT_VARIANTS = { QUICKVIEW_BUTTONS, MOBILE_ICONS,

    FADING_ICONS, } <ThreadSentiment variant={SENTIMENT_VARIANTS.FADING_ICONS} /> @Jack_Franklin 76
  77. The key here is to explicitly allow just a few

    And you can apply CSS classes accordingly. .itemSentiment { ... } .itemSentimentVariantFadingIcons { ... } @Jack_Franklin 77
  78. Always favour explicit code over implicit knowledge @Jack_Franklin 78

  79. Beware breaking the abstraction @Jack_Franklin 79

  80. We've talked about how components should be black boxes. @Jack_Franklin

  81. A good way to figure out if you're sticking to

    this is this: Could you take a brand new project, and place your component into it, with no other set up required? @Jack_Franklin 81
  82. But the answer cannot always be yes @Jack_Franklin 82

  83. Some of your components will have to talk to the

    rest of your application. The trick is minimising how many and coming up with a structure to it. Don't allow any component to implicitly rely on some data. @Jack_Franklin 83
  84. Giving components data. @Jack_Franklin 84

  85. 3 approaches —Components fetch data from your server via an

    API call —Components are given data from the server when it renders the HTML —Components parse data left for them in script tags @Jack_Franklin 85
  86. APIs 1. Component initially renders a loading spinner (or nothing)

    2. Component fetches from /your/api/some- endpoint.json 3. Component updates to show the data it has. 4. Component updates to show an error if anything went wrong. @Jack_Franklin 86
  87. APIs ✅ ❌ Ensures we always have the most up

    to date data Adds extra loading state Easy to re-fetch the data if we need to Introduces chance of error Component is network dependent Component will be slower to show data to the user @Jack_Franklin 87
  88. Data from the server <jacks-carousel items="{JSON from server}"> </jacks-carousel> @Jack_Franklin

  89. <thread-product-sentiment item-id="13191186" add-dislike="/xhr/structured-feedback2/13191186/negative" remove-dislike="/xhr/structured-feedback2/13191186/negative/delete" add-like="/xhr/structured-feedback2/13191186/positive" remove-like="/xhr/structured-feedback2/13191186/positive/delete" dislike-reasons-url="/api/negative-feedback-tags/13191186" sentiment="neutral"> </thread-product-sentiment> @Jack_Franklin

  90. Data from server ✅ ❌ We get the data immediately

    from our server Data might be out of date if the user has performed an action since rendering Fewer states to worry about (no loading or error) Creates long strings of JSON in HTML @Jack_Franklin 90
  91. Data in script tags @Jack_Franklin 91

  92. Write a small util around your global config import {

    getConfigValue } from 'lib/global-config' const userIsLoggedIn = getConfigValue('user.authenticated', false) @Jack_Franklin 92
  93. ✅ ❌ Useful only for data that needs to be

    globally available Can lead to a huge set of config if used too much. A good way of setting data that can be accessed from anywhere on the site. Won't be updated if the data changes. @Jack_Franklin 93
  94. Think carefully about all the different approaches and the ones

    that work best for each component individually. Type Situation APIs Good for data that changes and needs to be up to date Data from server Good for component specific data that won't change Global config Good for data that any component might need, and that won't change. @Jack_Franklin 94
  95. The path to components today ! @Jack_Franklin 95

  96. It's easy to introduce some of these ideas to an

    existing project. @Jack_Franklin 96
  97. Not everything has to be a single page application Servers

    are still useful. @Jack_Franklin 97
  98. @Jack_Franklin 98

  99. Take Thread, for example —~5 years old, built as a

    server side Django app that renders HTML via templates to the client. —JavaScript is layered on top via plain old JavaScript and jQuery. —We now have ~50 components (give or take) and that number is going up all the time. @Jack_Franklin 99
  100. @Jack_Franklin 100

  101. Wrapping with web elements 4 4 https://github.com/PixelsCommander/ReactiveElements @Jack_Franklin 101

  102. In our JavaScript: import ThreadItemCard from './components/item-card.jsx' document.registerReact('thread-item-card', ThreadItemCard) In

    our server's templates: <thread-item-card item="{...}"></thread-item-card> @Jack_Franklin 102
  103. We can introduce React and our component system without having

    to rewrite a lot of functionality that we already have on the server. And when we don't need JavaScript, we can still just render HTML and CSS via our server (!) ! @Jack_Franklin 103
  104. Dealing with legacy code CollectPlusAPI.initialise( $('.collect-plus-widget'), { ... } )

    @Jack_Franklin 104
  105. Wrap it in a component! class ReactCollectPlus extends Component {

    componentDidMount() { // legacy JS goes here CollectPlusAPI... } } <thread-collect-plus ...></thread-collect-plus> @Jack_Franklin 105
  106. The black box abstraction can be used to hide away

    bad code in a layer of good @Jack_Franklin 106
  107. The "black boxyness" of components lets you try new technology

    @Jack_Franklin 107
  108. How we adopted CSS Modules at Thread @Jack_Franklin 108

  109. ! Hey, I think that CSS Modules might be a

    good thing, for reasons X, Y and Z @Jack_Franklin 109
  110. ! Sounds good to me, let's try it! @Jack_Franklin 110

  111. ! So I built our new component using it -

    what do you think? @Jack_Franklin 111
  112. ! Looks great, let's ship it and see how we

    find it on our next few projects. @Jack_Franklin 112
  113. After a few weeks we can decide either way. @Jack_Franklin

  114. Yes, all your components should be written using the same

    set of tools and techniques. But launching one that's built differently to learn about something provides a lot of value. @Jack_Franklin 114
  115. It's easy to get distracted talking about the benefits of

    a new tool/language in theory But components let you just do it. @Jack_Franklin 115
  116. To sum up... —Keep your components small and be wary

    of too much configuration —Beware anything that breaks the black box abstraction —Prefer explicit code over implicit knowledge of how your components interact —We're all figuring this out together, as we go. @Jack_Franklin 116
  117. It's a very exciting time to be a front end

    developer! @Jack_Franklin 117
  118. FRONTENDNE for 50% off https:// javascriptplayground.com/ testing-react-enzyme-jest/ @Jack_Franklin 118

  119. Thank you. @Jack_Franklin speakerdeck.com/jackfranklin We're hiring! jack at thread dot

    com @Jack_Franklin 119