HN user

dylanjha

145 karma
Posts15
Comments25
View on HN

Styling components nested inside other components can still work with either slots or scoping CSS custom properties with parent selectors.

.login-form { --button-outline-width: 2px; }

.credit-card-form { --button-outline-width: 2px; }

Of course, the component needs to be authored & documented in a way that supports this.

For example, shoelace has a "Drawer" component: https://shoelace.style/components/drawer

By default the drawer component has an "X" button in the header to close it. If you want to override that, instead of trying to style the nested "X" button you can pass in your own header actions with slot="header-actions"

think there is a clear tension between the component desire for encapsulation vs the web designer wanting to impose their styling on the nested components

This is the inherent tension. It requires good web component authoring to expose:

1. `part`s that can be accessed by application-level CSS

2. slots for the application developer to inject html

3. CSS custom properties (--variable) -- these pierce the shadow DOM

The web component authors have to be very intentional about these things. There are good examples and bad examples and I think people are still learning how to do this well.

I see. Particularly with CSS there's more of an enforced contract around how the element internals get exposed for styling. If the element hasn't exposed `parts` or slots it's hard to hack around it.

More broadly speaking I have found myself getting thrashed by the ever evolving "best practices" in the React ecosystem. First: write everything using class components, and then a couple years later everything should be written with hooks.

I think the benefit of web components (for certain things) is that the APIs and the standards move slowly. Something you write today isn't going to feel obsolete in only a couple years.

(author from Mux here) -- that is correct. For the stuff we build for in-house use on mux.com and dashboard.mux.com we have a components library written in React.

You nailed it that we are shipping SDKs with visual components (like a video player) that need to be compatible across all kinds of frontends.

Instead of N number of SDKs to maintain where N is every front end framework, we have 2: a web component, and a React wrapper around the web component. Maybe in the (near) future we only have to maintain 1.

It's amazing how the web has come full circle now.

2023 web developers: I figured it out y'all. Send HTML from the server.

1994 web developer: ...excuse me? What else would you do?

Even though I’m not deaf or hard of hearing, I find myself using captions more and more when I consume video content. I don’t think I’m alone in that. I saw something a while ago that tracked this as a broad trend. Today’s accessibility is tomorrow’s usability.

I also work on player stuff with OP and learned a lot in this process.

Neat idea. Anything to share about how you launched this? Is it on Shopify or another ecommerce engine?

I've heard that Instagram oauth access can be difficult to get approved for production use, were they giving you a tough time when you went through the approval process.

GatsbyJS Review 7 years ago

Nice post.

I’d also love to see a future where we can just plug in a normal image tag and have all those image processing features out of the box.

This would be great. Currently, headless CMSs are doing this pretty well (for example, Sanity: https://www.sanity.io/docs/presenting-images) but I could see tools like Gatsby offering that too.

I don’t see Gatsby offering much of a value proposition to people hoping to use it commercially, but I think that paradigm shifts, like PWA becoming a standard that customers will begin to demand from their sites or an increase in the popularity of Gatsby themes leading to a much faster development workflows, could easily help Gatsby overcome some of the competitors it is facing in various areas.

Your points about NextJS are valid but I think there is plenty of room for a few different static site generators to live and thrive in the ecosystem. Even if the differences are small and you can do the same thing on multiple platforms I for one hope we have multiple platforms competing and doing well, the competition will lead to faster innovation and ultimately better tooling for developers.

Video is hard to get right, with quirks across many combinations of platform/device/OS/browser version/video card/playback resolution/format features

Video is really hard to get right, a Hollywood-style big bang launch on day 1 is difficult to pull off for any software, let alone video.

I feel for the engineers working there, I wonder what the meetings were like last week, did the engineers know they were not prepared for this?