TL;DR - You can render viewport specific components in React with a one-liner
React is awesome and the whole world agrees to it unanimously. Dev...
For further actions, you may consider blocking this person and/or reporting abuse
In my opinion this goes against mobile first principles. On occasion having device specific content is necessary (like you mentioned with the menu), however, if the component is handled appropriately, media queries is all you need.
And with your approach you're still having to write device specific styles.
I also see your point in wanting to min/max. Even if you handled the menu with specific device media-queries, you would still be loading the media queries not needed for desktop as an example.
I still stand with if media-queries can handle the change, then you should stick with media-queries without having to write device specific components.
20kb is quite a bit to just handle one device specific view, the menu must be really massive.
Mobile first approach is the dream and I agree that this goes against mobile first principles but in my experience there's always something that cannot be truly responsive and needs to be handled with media queries.
Yes, but these styles will be composed for specific components without having to be wrapped in css media queries.
Not necessarily. If you use css modules or any css-in-js approach, your styles will be a part of your component and not separate stylesheet. But this is true if you extract your css into one big stylesheet. Instead you could separate your stylesheet for specific components and lazy load them.
I hear you. You don't need this if the application or requirement is small. But if your application is huge and if you often find yourself writing device specific media queries, this will make you happier.
It was one big bundle of bloated foundation elements wrapped in React components with a very high level of customization.
I'd say it depends on what you are building specifically. If it's for visual presentation, then yes you should use CSS media queries. But this would be helpful for when you want to serve different components for different device types (say a bare-bones video embed for phones, but a full featured media player for laptops up).
It's a brilliant idea. Keep doing great stuff, Dinesh!
Simon - What would help everyone is if you could explain the "performance costs" you quoted here.
BTW, as much as I wish my best for the commendable work you've put in your lib, I don't appreciate you promoting it here. If you wanted to improve this lib, you could've created an issue and we could have worked on it together. But if you want to promote your lib by dismissing what I've built, I don't appreciate it.
In the sake of performance I would choose an extra element + media query over a resize listener updating state on every pixel. I think a nice feature would be to enable a throttled resize to minimize re renders and help with performance
I agree that state change on every pixel of resize is a major overhead, but in reality we resize the browser window often only during development to check different viewports. End users don't do that that much.
That definitely has to be done. There's a open issue for this throttling the window resize event. Planning to get this done soon.
This is interesting and I love the name! React Socks.. lol
Haha. Thanks Eric. I had sleepless nights trying to come up with a good night. Finally gave up to 'looking at one of my socks lying on the floor and naming the package'.
Whoever said "naming things is the most difficult part of software engineering", said it right.
One other user in a reddit forum suggested to look into
matchMediaand I think it's really interesting.With this, we could let users to pass in custom css queries on the fly.
Awesome work Dinesh!
I'm in love ♥️