Media Queries vs Custom Components – Steve Hawes
Steve Hawes talks about why he wrote a custom component instead of using the bundled one
Right, I don’t have any slides, so I’m afraid it’s just going to be a straight demo within the code. My talk actually was this, is media-grims versus custom components, but it’s more about how we did or why we decided to build a custom component. There are some great sort of body components and the vast majority of applications can do what they need to do with the components that are shipped with server-point. Occasionally you have design and you can use one that will come up with something that can’t be done by loading components. And just to give you a quick example, this is what our designer came up with for a new design for one of our portals and the navigation bar at the top has this dropdown area that comes up as cards instead of your standard dropdown menu. The server and that bar would have been the natural thing that we would have used for this, but even with the CSS playing around with CSS we were able to get a card display because of the extra subtext that’s the idea for each item in the menu. So we decided to go for a custom component. The custom component that we have built is this one, the map bar at the top here and I put in a equivalent server in that bar down below. One of the functions from the existing server in that bar that we wanted to maintain a carryover was the responsiveness because this is one of the few components that’s actually responsive within a CSS layout. And what you find with the server on that bar is as you collect your screen, it collapses into a handle of your menu where you get your options and ours that’s much of the same, slightly different layout, but we’ve maintained our card layout for the menu. Now that’s all great. The server component does the responsiveness using CSS media queries. There’s one slack drawback for the media query. The media query relies on viewport size which works fantastically aware to show it better. However, if you stick your nav bar in split pane and collapse your split pane, I would have now still collapses, but the server one doesn’t and if you carry on collapsing, it just drops into itself. And the reason we built it like that is because we use a lot of split bars within our application and we use nav bars within split bars. And the way we achieve this is by using something an API that’s within the browser called the resides and server. So if anyone builds their own components, it’s a very, very useful API. I’ll just show you the core of it. Well, actually I’ll show you the server core first. So if you look at our form, in our nav bar, we’ve kept pretty much the same properties as our own server one. The server one has a collapsing property called true of all, so if you set it through your will collapse, if you set it to the bottom of the layer, we have a similar property called collapse, but we get some extra properties in there, one of which is the width. And that is the width that you want the property, the nav bar to collapse on. So if the different size splits and things, if you know what’s going to be in the menu, you can tell exactly what size you want into collapse. That translates into our component by using a resides and server. And for anyone who’s familiar with building components, it’s in the TS file, you just create a variable that’s a type resides of server. So command plus lock control, burst command plus command plus command plus command plus. Yep, is that better for everyone? So you create a variable of type resides of server, and in our on-changes, if we have the correct property defined, we create a new resides of server. And all you pass the resides of server is the function that you want to execute when something resizes. And that function will receive you a list of the elements that become resized and their current sizes. And so we say, for every element that’s in that list, get the board of oxides. Now there’s three types of properties you can not get. You can order the board of oxides, the content box size, or the pixel device pixel of box size. We went to the board of oxides, because depending on your design, you can submit the size of the component with order changing. If you don’t look at the board of oxides, if you look at the content box size, if you board it gets bigger, it doesn’t get triggered. So you create a function, and what all we do is say, if the box size, current value, is less, if our current value for our component collapse is larger than the current box width, then we remove the class show. So take the element, it takes the show class away from it. It will add a class called at barclapt, which lets things know that this now in the collapsed state, and we toggle the show class react, the show class to the hamburger button. So the element that needs to be clapped disappears, the button appears. Otherwise, if on the resize, the actual size of the box is bigger than we want to, than our minimum size, it does the reverse. It shows the class element, and hides the hamburger button. So that’s the function that we’ll get called when something resizes. You then tell your observer what it needs to observe. And you pass an element, which is this bucket native element, so you’re looking at the element itself, the component, and you tell it what box you want to look at, which is the board of ox. You can pass multiple elements to one resize of the observer if you want. You can create one resize of the other and pass multiple things to it, and that one function will get triggered if any of them get resized. And that’s about it, really. Probably a lot less than 10 minutes. Yeah, good. You’re going to have three minutes left. Any questions? I’m a curious number now. Picture of who creates the wrong custom components here. Do any of you already use the resize of the observer? Was it something you were aware of? Is it something you might find useful? That’s great. That’s great. Thank you. Thank you.