It is not the only thing for which the example I copied is incomplete to work fully when Javascript is disabled. When we click on the background, we click on the fixed positioned .modal-fade-screen. And there is a Javascript code to take care of it. This is why I cannot remove the js directly and use a label to close as you suggested. But I found a solution for this using a react ref.click() in a callback.
It seems to me that they wanted to minimize the Javascript code, and not just make something work when Javascript is disabled.
There are performance benefits of using CSS for the opening/closing and not Javascript. The jquery code needs to parse the DOM tree to find the element. Using CSS and not Javascript releases resources to the Javascript thread to be used for other things. Event handlers are constructed by the class. With react, the event handlers are reconstructed at every render(). ANd if callbacks are passed to sub-components, it may create even more render than needed. It often simplifies the code to use inline js handlers with react even if it is a known bottlneck. In the Js inferno library (a library like react), they claim in the doc that not using event handlers helped to make the framework very fast. This is quite theoretical and does not really apply to a simple example opening a modal.
Imagine I have a class with 1000 modals. For example, displaying search results, each has its modal. Then there are less event handlers to construct. The label to close would also reduce the number of event handlers.
PaulOB, can you confirm on the performance difference?
I donât really like the idea of using a checkbox hack I donât really need. But if there is a small performance optimization in it, then I like it better as a generic component solution.
I addressed that in my comments and said that to close the modal when js is disabled you need to click the close icon only.
In my mind clicking the background is somewhat a âmystery meatâ navigation and a lot of users will not know about it or indeed like it if they click accidentally and the modal disappears.
Itâs not about you its about your users and a modal that works with js is disabled is preferable to one that doesnât.
I doubt that you will ever notice any perceived performance bottlenecks in creating modals for your purposes. If you are creating a 1000 modals then you are doing something seriously wrong. A modal should only be a quick reminder of something or perhaps an enlarged view of an image. If you are using it for anything more complicated then please navigate to a new page and do the job correctly.
Small login forms are fine for mobiles but not for anything larger where a click on the background loses you all the data you entered!!
I donât believe the script you are using is actually doing anything less anyway just because the css was in place. It was used in tandem with the css as can be seen in the web developer console when you click the modal âbuttonâ. There is no gain to js by using the checkbox hack in css.
I am not using 1000 modals. I am using 9 modals. The performance difference is indeed not relevant for my use case. I was just interested in the general case if CSS hacks skipping Javascript could have a performance impact. I just wanted to know your vision of it. When they comment about even handlers being bottlenecks in various documents ios (of react, of inferno.js), it is more a general rule.
In my use case, there is another benefit of the CSS hacks. I donât have to use jquery, and I donât have to manage the state in Javascript in React. I see this as âreduced couplingâ and a simplification. Jquery being a global access to the DOM tree, it has high coupling.
Do you mean that given the âconfused commentsâ I wrote the final solution I would be using would not use less Javascript just because I copy the CSS Hack?
After the discussion, I understand the CSS hack now. And I use less Jaascript to open and close the modal.
That class could have been used to open and close the modal instead of using the checkbox hack so there is not less code just because you used the checkbox hack.
In short, react uses a virtual DOM with a smart way to diff changes and only update what has changed. With JQuery, the DOM tree needs to be parsed to search for elements. With react, elements are more local, you can keep a reference to them and use the reference inside an onclick() callback. So react, has in particular 2 interesting things: smart update of the DOM, and no global event system parsing the DOM tree as with jquery or getELemenById().
There are also bottlenecks in react. The most popular use of react to manage the state is to use redux. Every change in the data with redux will trigger rerendering ( calling a function render() that creates the DOM elements in JS) of the components that need the data. Callbacks are often reported as bottlnecks since every render creates the callback functions. In react, it is often recommended to bind the callbacks outside the render function. One library, inferno.js, among all popular libraries (react, vue, angular) claims to have the fastest performance in particular because of having no need of binding or constructing callbacks. The callbacks are only represented as JSON.
In this context or react, for which callbacks cause performance issues, it is interesting to use a CSS hack to reduce the number of Javascript callbacks. It does not matter in most use cases. But it is one way to optimize.
I have used quite a lot the Google maps API in Javascript. And I always found it extremely slow to update things. IT shows that even in simple application without that much content, optimizations are needed.
I wonder if transfering effects from Javascript to CSS is a good approach to optimize. In browsers, the CSS engine is often multi-threaded. Javascript is single-threaded by default. WHat I say is only speculative. I did not measure anything. But that would interest me to see.
