Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we use web components

github.blog

Post reply on HN
Print view View original

21–30 of 84 posts

Re: How we use web components

#21

Post by 1337shadow »

WebComponents are an amazing replacement for jQuery, get the best of frontend Component based development without the bloat and the JS toolchain! Vanilla JS is great with WebComponents. We even write them in python with Ryzom's transpiler:

```

class DeleteButton(Component): tag = 'delete-button'

    class HTMLElement:
        def connectedCallback(self):
            this.addEventListener('click', this.delete.bind(this))

        async def delete(self, event):
            csrf = document.querySelector('[name="csrfmiddlewaretoken"]')
            await fetch(this.attributes['delete-url'].value, {
                method: 'delete',
                headers: {'X-CSRFTOKEN': csrf.value},
                redirect: 'manual',
            }).then(lambda response: print(response))
```

Speaking of which, Rails ViewComponent looks a lot like Python Ryzom, except the later optionnaly supports data-binding over websockets.

But writing JS in Python is extremely satisfying if you already like writing Python more than you like writing JS ;)

Re: How we use web components

#22

Post by bryanrasmussen »

DanielKehoe wrote: post #13
cageface wrote: post #4

Earlier quoted context omitted.

I've just started using it on a fairly simple project so I only have first impressions. But it seems like for a UI that's not too complex it could be a big timesaver. I need to spend more time with it before I can decide where I'd draw the line and switch to a full blown SPA but it definitely expands the class of apps you can build without much JS.

State management on the front end? Is that the differentiator that forces the need for a full SPA framework? Anything else that can't be done purely with web components?

I think the only state management that really requires SPA is of course the state between pages.

But why actually have pages - I actually think this is a good differentiator of if your site is naturally an SPA or not - if you really need pages, perhaps because people need to be able to bookmark a specific part of your site that is more important to them than other parts - your site as a whole might not actually need to be an SPA although it might have parts of it that function as SPAs.

Re: How we use web components

#24

Post by 1337shadow »

lgessler wrote: post #18

Something I've never understood how to handle with vanilla web components: if there's some state that needs to be shared and kept in sync between multiple components, how do you do it? (For comparison, in React you can pass the state down as props from a common ancestor, and in Clojure frameworks all app state is in a giant object referenced by components as needed.)

You just addEventListenner on change or input and update your state. Nothing special here.

Re: How we use web components

#25

Post by timdaub »

I started using ficusjs for some experiments [2]. I built a signature button for Metamask [1].

What's great is that:

- I use preact's htm as a renderer [3], which is JSX but as template strings.

- The API is like (p)react but a bit more generalized. I like it.

- The web component concept is great. Especially for mixing server-side rendering and JavaScript-powered components.

That last one IMO is web components killer feature. I can now wrote a mini component and then I tugg it in with the other 99% of my page that is rendered server side.

It means, I'm able to serve my users quickly. I have SEO'd everything too. Cool!

-1: https://github.com/TimDaub/web3-sign-msg

- 2: https://docs.ficusjs.org/

-3: https://github.com/developit/htm

Re: How we use web components

#26

Post by aitchnyu »

In my side project I use Vue CLI's async webcomponents target to generate a webcomponents.js can be imported into a script tag and . I was at a loss how to include compiled SFCs (components) into a server rendered app. IME, Vue tooling assumes a Node JAMstack SPA and the Django boilerplates were a pain. Guys who wanted to sprinkle interactivity to their apps were at a loss.

Re: How we use web components

#27

Post by jjcm »

jpangs88 wrote: post #14

At my work web components were purposed recently for creating a ui component library of which I was skeptical. On the whole I was skeptical of web components viability and future but this post relieves some of that tension. The other thing I was worried about was that it was planned to after writing this web component lib, to wrap these components in React. Does anyone have any experience or insights into a React wra…

Super easy to incorporate with React. Just use react to pass attributes, like so:

    class App extends React.Component {
      render() {
        return (
          
        )
      }
    }
In your webcomponent just make sure you listen to changes to that attribute like so:

    static get observedAttributes() {
      return ['custom-attribute']
    }
Then you can decide how the component changes whenever that attribute is updated by using the `attributeChangedCallback` function. Alternatively, use a base element that incorporates a render() function which will automatically update everything in the shadowdom.

Main difference is it becomes much harder to pass complex data structures. Passing strings is easy, but passing an array of data isn't feasible with this model.

Re: How we use web components

#28

Post by jjcm »

brailsafe wrote: post #10
jjcm wrote: post #8

Earlier quoted context omitted.

I’ve had mixed results. Page speed is excellent - I built out an SPA with ~60 or so components and my uncached first paint happens in about 400ms. Cached I get 250ms (this is on prod so it includes the server latency). SEO is more difficult. I’ve been using the npm package prerender to serve up the page properly for Google/Facebook/Discord bots and for crawlers, and since using that I’ve had successful parsing, but a…

Why don't you cache the prerender and serve to everyone?

I'm using a static html file for the full app. The client side selectively removes/adds html for each of the pages depending on the url. Upside to this approach is that static = fast. Downside is if I prerender then the routes don't have the initial context for navigation to other pages. The prerender shows only a subset of the full site. I'd have to re-architect the client side router I wrote to support it, and that's very low on my MVP list, especially with performance in the 200-400ms range as it is.

Re: How we use web components

#29

Post by jjcm »

lgessler wrote: post #18

Something I've never understood how to handle with vanilla web components: if there's some state that needs to be shared and kept in sync between multiple components, how do you do it? (For comparison, in React you can pass the state down as props from a common ancestor, and in Clojure frameworks all app state is in a giant object referenced by components as needed.)

For passing upwards I typically fire a custom event, with data in the detail field. For passing downwards, I have the parent delegate attribute changes on the children as much as possible. This limits you to only passing string values downwards, but it keeps the html mirrored to the state, which has a simplicity to it that I prefer.

An example of this would be a radio-group and radio-element. When an element is clicked it fires a "clicked" event to the parent radio-group. The radio-group then toggles on "selected" for the clicked element, and removes the previously selected element's "selected" attribute.

Re: How we use web components

#30

Post by esprehn »

jpangs88 wrote: post #14

At my work web components were purposed recently for creating a ui component library of which I was skeptical. On the whole I was skeptical of web components viability and future but this post relieves some of that tension. The other thing I was worried about was that it was planned to after writing this web component lib, to wrap these components in React. Does anyone have any experience or insights into a React wra…

It works alright with React if you treat it like regular DOM elements, but there's rough edges like SSR event handlers not working: https://github.com/facebook/react/issues/18390

Unfortunately it seems facebook isn't prioritizing fixing issues like this.

I'd suggest using preact if you want a framework that's more compatible with web components but gives you the React experience.

Post reply on HN