You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you do server side rendering (SSR) you don't necessarily need to hydrate your entire page if most
of your content ist static and only some parts are interactive / dynamic. That is especially true for
a newspaper website, which ich what we are working on.
What you want is partial hydration, sometimes called or related to progressive hydration or lazy hydration.
There are a few implementations out there to achive this, for instance
second-dehydrator
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the “Software”), to deal in the Software without
restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When a MobileSafari keyboard-receing input (e.g. an input[type=text]) receives focus in Safari, the system will try to verify whether there is ample room to bring up the soft keyboard without needing to scroll. The amount of wiggle room needed for Safari to consider available scroll height "ample" seems to increase with every major iOS release (surely to work around the very real problem of focus being granted to inputs that are subsequently oscured by the keyboard).
However, for "app-ey" web sites that carefully place each text input in a relatively fixed layout, this can be a maddening arms of scooching up my content more and more with each iOS release to avoid awkward jutters every time the keyboard is shown (example video here. In practice, it seems like the input's scrollHeight can only really be about the equivalent of 15vh before you're likely to get an automated scrolling whiplash from the soft keyboard, which isn't much
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
“In what way is JS any more maintainable than CSS? How does writing CSS in JS make it any more maintainable?”
Happy to chat about this. There’s an obvious disclaimer that there’s a cost to css-in-js solutions, but that cost is paid specifically for the benefits it brings; as such it’s useful for some usecases, and not meant as a replacement for all workflows.
(These conversations always get heated on twitter, so please believe that I’m here to converse, not to convince. In return, I promise to listen to you too and change my opinions; I’ve had mad respect for you for years and would consider your feedback a gift. Also, some of the stuff I’m writing might seem obvious to you; I’m not trying to tell you if all people of some of the details, but it might be useful to someone else who bumps into this who doesn’t have context)
So the big deal about css-in-js (cij) is selectors.