If you mean some custom scripts, there is matchMedia/supports apis you can use to target some specific devices
I am not sure what you mean by client request details
Showing/hiding components depending on what exactly?
If its screen resolution then it should be media query, which is basically right now breakpoint
If its user agent, then you will be in trouble, this this is very tricky
Generally device sniffing is bad, you want to rely on device characteristics aka feature detection, not specific makes
Device sniffing has been proven over and over as a bad approach
Sorry never got back thanks Bogdan.
Media queries still serve up the info. Was looking for a way to conditionally not serve it (ie. bind something to show/hide field)
Was a very small thing though so I'm not pushing for it. Just and idea
Ok so basically media queries but for show/hide property?
what would be a concrete use case?
but screen size isn't reliable because it could be a desktop that is narrow then the user widens it
use case, i have a script that impacts only the desktop interface. It's not needed on mobile at all
more concretely why do you have that script?
it's for navigating my ui in desktop. There is extra functionality i add for desktop users given the extra screen space and keyboard (listens for arrow keys)
so you want to show extra UI when there is available space?
yes but also i have a script for that UI. so the script is useless on mobile
and you need to detect if the device is touch device
touch device would be a good indicator
you need 2 things: touch detection and viewport size
how? doesnt media query still serve up the info jsut not show it?
@media (hover: none) {
a {
background: yellow;
}
}
touch devices have no hover
yeah all that still gets send to the client. i want some logic server side that says oh touch device, don't serve up this script or section
but i don't really need it
why on the server though? isn't it client-side app?
would make sense in that case to not send that functionality from server at all and load it conditionally on the client, no?
just playing devil's advocate here
to dig out the truth about the case
detecting touch server-side doesn't really work, because agent sniffing is unreliable
there are only 2 good options:
- sending server-side but not showing where not needed
- not sending server-side at all, showing when needed fully client-rendered
I thin the second option is very interesting, and we need to look into how to make lazy loading components client-side possible
And actually its already part of the framework, it's basic router feature that allows you to load something based on a subroute change.
Potentially all custom logic would have to do is to conditionally change the url.
e.g.
if (isDesktop && viewportWidth > 12345) {
const url = new URL(location);
url.pathname = '/something'
history.pushState({}, "", url);
}
hm interesting. my use case is small but lets make it bigger. lets say i have a 2mb script that only impacts my desktop interface. useless on mobile. Currently, that script gets served up no matter what.
But I guess understanding the device is difficult and my use case isn't big so really no biggie
that clearly sounds like a client app
you want to conditionally render it once initial app is loaded
it creates some waterfall
no i want to conditionally serve it
but prevents loading upfront too much
you want to conditionally render it that mens fetching everything it needs to render when the condition is met
this is a basic client-side routing
that's by default how it works
e.g. we don't fetch all components from another page when user visits first page
see that conditional view like a separate page
i think the difference is its not conditionally rendering it after the app has loaded, it's conditional as of the very first request
its the same thing technically
you can't do that based on properties like touch device since it can't be detected serverside
thats why i said user agent, but i guess there are issues with that
yep, not possible, you will end up with some shit 🙂
