Norbert de Langen - Building a Maintainable UI with Storybook | ReactNext 2018

[Music] hi everyone as introduced my name is Norbert along and I'm a full-time open-source maintainer and the thing that I'm maintaining is storybook so today I'm gonna be talking about storybook but I want to start out with like why and and what made it come to be for meet firstly needed at some points and then later start maintaining it and so reason number one really is a pretty depressing message it's that writing apps is hard I find it hard if you doubt that writing apps is hard ask yourself like how often are your software estimations correct are you off by an hour a day a week a month like I've been off by a month at least more than once so that the factor standard solution to this problem is split up your big application into smaller applications right that's the answer well you do run into the risk of creating this distributed monolith so you start out with this huge component that does all of your app and you break it up into smaller pieces but they're still magic they're they're still components needing each other to be there and it can be quite hard so I ask the question again is decomposing your big application into smaller pieces the answer yeah yeah it's the answer so thanks I was there good short talk all right so seriously I do fault full-time open-source maintenance and really proud of that I think it's really cool to work an open-source I encourage anyone to work on open source either as a spare project or come help out with story book I do software advocate our software developer advocate for chroma that's kind of a formal title something I'm proud of I'm a father and a husband of daughters for yourself five years old and personally I don't really have an idea of what I'm doing I'm just going along with the flow so I want to start up my real presentation about I've been doing consulting for years and this is a scenario that kind of came up it's not an actual company but sort of a hypothetical scenario that you might recognize a company they're billing a software-as-a-service and if their application is pretty big so they've decided to make their UI split into three different teams team one is responsible for something like check out another place for the front homepage and not a phone or whatever it doesn't really matter as time progresses teams are kind of making a request to each other like hey can you make this change to your code over there that's kind of easier for me and it kind of happens over and over and it's taking time and for the company that's costing money and it can get to the point and I've seen this where there's tensions between the teams because the use case that team a wants is not what team B really wants and it's their component so they get to decide what really goes in and the team a is kind of like unhappy now to have to forked or copy it and no one likes copying code so what can we learn what can we do and how can we build are you wise to minimize this process and I think the key constants that I've kind of learned our abstraction isolation and autonomy what we want to reach is teams and all individuals to be autonomous so they can make changes whatever they want and they don't really need to change someone else's property I think most software developers will know that a good abstraction is really the key to good software if you create abstractions or you shouldn't you get complexity if you don't create an abstraction where you should you get complexity also and if developers are like ninjas or Knights and they're fighting complexity and complexity is the dragon that we're trying to slay and I think is there funny synergy there that if you fail to combat this dragon effectively you're effectively feeding it and making the problem worse up to the point that the dragon is fed so much it is so powerful no single night can ever defeat it which is the concept technical depth and it can reach to a certain degree that you basically filed for bankruptcy so to create correct abstractions you must understand the problem well and an abstraction is nothing else than a solution to a problem and I think of a famous quote it's kind of in the theme of my talk about combat the art of war Sun Tzu wrote that if you know your enemy and you know yourself then you don't need to fear battle but if you don't know yourself where you don't know the enemy then you need to be fearful and they don't know either one you're gonna lose so isolation is the possible result of good abstraction or better worded good isolation is the possible result of good abstraction we all know probably that an isolated component that's a component you can just swap out for another one so it has a similar API that's not really what isolation is about it's really about the API of your component isolated pieces will have some sort of API for communication and is this API in react terms the props that determine whether your component that you've created for your team for some other team is gonna be loved or despised there's a trade-off in isolation and I've seen many cases where that component just isolates too much and this is really what drove me as part of the gift is target it's something that I've learned over time including maintaining storybook if your component isolates too much your API will have to grow to compensate for its multitude in use cases and that will increase the components complexity if your component does not abstract too much and it doesn't isolates too much and it has a nice API to do the things you want to do then you get components that don't really have to change all this often and when the components do change they're not you're not changing an opponent as like ten different use cases there use cases are limited so they're simple they may have States they may be context-aware but they're simple because they're number of use cases are limited and therefore because these components don't need to change that often they're much safer to reuse because you don't really want to use a component that is isolating too much for multitude of reasons one of which they're gonna be changing all the time because they're adding new use cases you know this upfront and because they don't change their make they're really safe because you don't have to ever update them and that's when you get into this autonomous state you can use a component and it's safe it will not really change because it doesn't isolates too much so react components they abstract a section of UI right I think the react talks themselves mentioned as a slice of here uy so sort of I think I try to write my components not as like a visual slice of my UI but as a abstraction on a UI pattern or concept this is really different from a visible section of the UI now these UI concept can definitely be visible otherwise you would not be presenting any pixels to the screen right but they can provide so much more two components lower down that do are visible they can provide data they can provide state or layout or they provide some Styles and a well implemented UI concept should abstract and isolate only one concept if you extract too much the users of your components are going to suffer so here's a little example and I've kind of taken this example from Kent C Dodds so I want to give him full credit on this component I've tweaked it a little bit so it made my presentation more fit my preference so this component it's an accordion component which probably all written it once in our career or multiple times maybe is this a good level of abstraction is this a good isolation razor has if you think this is the proper way to write a accordion component so I think there's a problem with this and that's it isolates too much these items that I'm passing in how how are they displayed what do they look like where does this purple or pink border coming from where's this plus and minus icon coming from this isolates too much you can see the pattern and the problems increasing when you add new use cases so another team member comes along and says some of my product owner he really likes it if the content appears on top can you make it this way all right I can do that it's not hard I'll just add a prop and it's a boolean value if it's true the content displays on top if it's false the content displays on the bottom and you know you guessed it so someone else comes along I said can you display to the panel the content on the right I think that's gonna be made much prettier also I kind of want these icons to appear as different icons right okay then someone comes along and just kind of get into this huge mess of all sorts of props you're gonna have to document all these props and you're gonna have to tell the user like okay you should never use the content classname together with the open trigger because that will not work and like you don't want to do that this is not all three so way to combat it like one of the ways you can come up these many props so actually create what I call preset components and these preset components they take or they are actually abstracting away a couple of props from some other component so you're able to use the accordion component to just pass all the props to it but you can also use the accordion bottom single component and it basically abstracts away the bottom prop and a single problem now I think this is an all right solution but there's at least one problem with it and it's one of the two hard things in computer science naming things how do you call this accordion bottom single component I could not come up with a better name and I tried so design your component so it encapsulates a UI pattern and no more no less because if you abstract and if you could abstract correctly you must understand the problem well know where we're going with this actually want to show you an accordion component that I've implemented in about three lines of code but first I want to really think about and this is something I don't want to give you as a tip when you're creating components the first thing you should probably do is write down maybe in your code as a comment the purpose and the concept that this component is going to be obstructing or it's gonna be isolating so I did that for my hypothetical accordion I actually thought like hey this is actually not just abstract away accordions but also tabs and carousels and many other patterns and I can reuse that so here's what I call my switcher component and it takes just one prop and that's the initial state it's an array of once and zeros because I'm lazy I don't want to write Falls and boot and true like it's way too much typing and then it takes a render prop so who's familiar with Brenda props cool all right so I'm gonna explain it because no less than 50% of fingers so in react you can pass in prop pass in children you know this you can have a div and there's a span inside it reacts actually supports any data that you can pass into as children it can be a string you've probably done this but it can also be a function now what happens if you pass in a function as it children well we are cannot render that but your component as being demonstrated by the presentation before me by Robert a component has access to children as just another prop and so what can happen and I will show you when I assure the implementation of Swit of the switcher component is you can call your children as a function and then you can pass in additional data so this is a way for still single unified data flow but it's from parent to child and so that's what I'm doing my switcher component has an initial state and then it's gonna be in control of the state and it passes down it calls the function that is children is gonna pass that function to values the list of the current state which is like an array of ones and zeros and then a function that the children can call to change the state it's sort of like a reducer if you're using Redux what does this allow well now I've completely separated the concept of switching the activity of items away from the items themselves and so now anyone can use the switcher component to create their own carousel or taps or accordion so a new use case comes up with this new switcher component which says all right so this one opens multiple tabs at the same time I can close them and I can close all of them now someone comes along and says ok I want to make sure that at least one tab is open they cannot close the last tab and only one tab can be open now my previous component the carousel component actually had this ability but it was built-in and was abstracted away so here's what you can do as a switcher component you can see what is actually happening is that the switcher component is not changing and in fact the item is not changing both of these components are completely stable but what I've added this is one little helper function called set which just uses the current state and it uses the function to set the state and then it passes this set function on on clickin and this is the implementation of my switcher component now granted I'm using the you state hook because you know it's been more than two days so we're free to use it I'm using children as a function you can see this right here so I'm this my switcher component i'm destructuring my props one of my props is children and then I'm calling children with actives and sedatives so the key takeaway encapsulate the UI pattern and no more and lo no less and I want to give you one more example and that's this layout component and a layout component is something that I really like to write because how many how much time do you spend writing your app making sure that div one is actually next to div number two or above in certain situations and this pattern repeats over and over again but if you think about slicing your application as you're just presented with a marker design you don't really think about this pattern you just kind of go with the flow and create these same patterns over and over again I think this is a great pattern to abstract into a component themselves and share and so what I can do is actually isolate or abstract away the sort of media query in a component themselves and it can show you that this component make sure that the purple content and the blue content appear top to bottom on small screens and next to each other on big streams so embrace using components beyond tea directly observable or visible but you kind of run into a problem with this and I think you know the solution which is like what my presentation started out with storybook so I can tell you that you've been looking at storybook all this time actually what does storybook do well you have so many components and at first things are alright you start out with your team but a few months later you don't really remember what what components you created two months ago and someone leaves your team and another team member comes in and comes along and they don't really know what you've been doing for two months have they that's really hard how do you know about this switcher component existing if you've never visited that one page it has the switcher component on it you don't you would create another switcher component because you might have some sort of convention of where to place files but even that is something that you need to learn so story book is like a catalog of all your components and as you can see it as sort of a workbench where you can take one component look at it in isolation play around with it look at it and meet multiple media queries and all that stuff you can document your components along with it is this size all right it kind of make it a little slightly smaller so my presentation itself like when I was building my presentation I created just a heading component and then I had all sorts of styles for it I had an avatar component and also his sizes for it had his layout components and I built it using story books because story book kana sets up webpack without much of reloading for you so you don't have to do all that in your app as I mentioned you can create pretty good documentation for story book in version 5 we're gonna be increasing that how much you can do with this by the ability to interleave your own components with your documentation as many people using either style guide issed or they want sort of more as a style guide yes and one of the cool features of story book is actually that we support all sorts of add-ons and one of the cool Ana's that I think we're actually really proud of now I'll show you in this searcher component which is also in storybook this one on the side so we've got this carousel component component and it's currently displaying the Dutch flag because I'm Dutch but um it's actually is Dutch flag apparently is not all that's accessible so here's an add-on for storybook to test the accessibility of your component it looks at your rendered HTML and runs a couple of libraries on it and the term is like okay so these are the things that are wrong with it so it turns out that the black text on red and the black text on blue are not accessible if I change them which I can using storybook right here I can make this sky blue and I'll change it here as well it's kind of resemble ste Israeli flag which apparently is fully accessible so as mentioned you can add your own add-ons to storybook there's a whole bunch of add-ons that we support in the new versions of storybook add-ons can appear in lots of places so you can do really cool stuff with them storybook allows you to take snapshots of all of your stories so you don't really have to make any snapshots manually anymore if you're into snapshot studies and you can add integrations into storybook so I actually work for the company called chroma and they build this product called chromatic I think it's pretty cool but obviously I'm biased to explain what it does if you have storybook and you've documented all of your components how cool would it be that if you make a commit that a tool run screenshot like literally visits your storybook and takes a screenshot of your component gives it if the previous time it's done that and tell you whether something has changed that's what chromatic does I used this myself before actually joining chroma and it actually made a huge impact on our team allowing us to get just code review but actual like visual review from designers before merging our commits into master which was huge we actually got a good collaboration with our product owners designers and developers so story book is open source if you like something or don't like something a story book you want to help we're really open a welcoming community and this is really one of the key takeaways for story book is something that I really believe in storybook is a tool not just for reactive a lover's but all UI developers and their team members we're trying to build a tool for all of them his storybook supports react react native angular view and you name it there's over like 10 different frameworks that we support and the cool thing about it is that an angular developer might need an add-on and create it it will work for react how awesome is that so I really want to thank this awesome awesome community for being so awesome and there's one guy and there's one other maintainer right here he's gonna come with them up right on the stage right now this guy is Igor and I feel humbled by his presence he's he does so much for the storybook community's really awesome guy so it looks like I have about twenty seconds left so I'm at my last slide thank you all for your time my presentation you can find right there so it's an actual storybook that you can see how I implemented everything all the add-ons that I've used if you have any questions feel free to ask me on Twitter like I actually like the winged support actually really liked it thank you [Music]

Channel: ReactNext

Views: 9,032

Rating: 4.9235668 out of 5

Keywords: react.js, react, reactjs, react next, reactnext

Id: 9lQMmbITt0c

Length: 27min 6sec (1626 seconds)

Published: Thu Nov 15 2018