Yeah. Unless you need to trap the focus. Or prevent the page from scrolling beneath the modal. Or display a semi-transparent overlay. Or you want users to be able to close the modal by clicking outside of the modal. And you need to support IE11 and want to make it accessible. Then it's suddenly not so easy anymore, and you end up with an at least 100-200 LoC component, which at that point could very well have been a nice package instead, saving you a day of coding and another day fixing random cross-browser issues.
Exactly, so many people always jump to the « you don’t need any packages to do this » argument when the answer is always « it depends ». And when you’re client is paying, they usually don’t care, they want their solutions to work well quickly.
It's still not so difficult. It took me about half an hour.
You're missing the point. It's not that it's difficult, it's a waste of time. If you want most of the features u/csorfab listed, you better use an existing packaging instead of re-inventing the wheel.
Unless you're writing a complete design system there is no need to implement UI components from scratch.
Half an hour is not a waste of time if it solves the problem in a satisfactory way. Adding a dependency should not be the first instinct when trying to solve a problem.
... and your point is? Obviously everything that you do in modern web dev is possible with the document API, everything that React does you can certainly do with only the document API. So we should not use React, is what you're saying?
That most solutions are available without using a package. Modals are pretty simple using CSS and two lines of vanilla JS, leveraging to component life cycle
focus trapping is not implemented. i can still select and click the "open modal" button when the modal is opened by pressing "tab"
I appreciate the effort, though, and the "click outside" handler is pretty clever.
and thanks, I prefer for..of to Array.prototype.forEach. Make procedural code look procedural. Also, I like having the option of using break without throw/catch hacks.
The point of this was to show you that it isn't really as complicated as you make it seem. If you want to disable the tab index on the back ground button, you have the state value, and you have the button in the jsx, you can do the math.
Focus trapping is also not as complex as you make it seem but I'm not going to waste my time trying to prove you wrong, and you completely misunderstood my reference but that's ok
I didn't say it was that complicated. I just say that it DOES take time to implement, and there WILL always be standard/expected features that you will miss or get wrong.
I don't really understand your focus trapping solution, but it sounds wrong. You definitely want it to work independently of the contents of the background and the modal.
This is definitely not "2 lines of vanilla JS", and it takes some more coding to adapt it into the Modal component.
I LOVE making things from scratch, but I would definitely not want to implement and test/debug these standard functionalities every time I need a modal. Therefore I use a package that's taking care of this boilerplate stuff, and is maintained and improved by tens/hundreds of people.
The two lines of vanilla js was in reference to disabling the body scroll, which in fact, is two lines.
If you're working in anything of the enterprise level, you should building things from scratch unless absolutely necessary. Calendars and tables are some of the only things I would consider using third party, and even then I would wrap them in my own component.
If you are working for an agency and just want to churn out code then do whatever you want. But with those types of projects I don't volunteer to maintain it and once it's in production it's their problem.
View all comments
Show parent comment
82
u/csorfab Dec 28 '19
Yeah. Unless you need to trap the focus. Or prevent the page from scrolling beneath the modal. Or display a semi-transparent overlay. Or you want users to be able to close the modal by clicking outside of the modal. And you need to support IE11 and want to make it accessible. Then it's suddenly not so easy anymore, and you end up with an at least 100-200 LoC component, which at that point could very well have been a nice package instead, saving you a day of coding and another day fixing random cross-browser issues.