Probably more complicated to setup in a hostile environment because you'd need multiple transmitters, which also need to remain stationary, or at least you need to accurately know when they move.
Knowing where the transmitters are is vital. So wonder if you build in a positioning system to them. Each transmitter transmits a signal, but also rebroadcasts the signals it receives from the other transmitters on separate bands (these can be at lower power). If you can pick up a few transmitters, is that enough to build a model of where they are relative to each other, and then where they are relative to you?
If each transmitter picks up the rebroadcasts if its own signals, then with some assumptions about the rebroadcast lag (or measurements of it added to the signal!), that's enough to know the range to each other transmitter, right? So maybe they do that and then just broadcast the ranges (tagged on to their main signal), then any remote receiver can work it all out from there.
> that's enough to know the range to each other transmitter, right?
Only in a flat environment without too much atmospheric distortions. As soon as you get multipath effects from eg waves bouncing off buildings and mountains then the computational complexity goes through the roof. Also I don't think you should underestimate how much the signal degrades in a "target path" vs the "direct path". The article mentions -60 dB and I think that is fairly optimistic. The transmitter power needs to be HUGE to make it work, so it would be much easier to have stationary transmitters. Normal radars manage to do this because they are highly directional, but multistatic radars need to look in all directions at once and need to up the power as a result.
Shopify heavily uses <template> elements with their Storefront Web Components project, except the templates themselves are passed as a child to the web component, that dynamically queries the data necessary to render the template, before mounting the element to the DOM: https://shopify.dev/docs/api/storefront-web-components
I'm on the dev team that built this. Happy to answer any questions!
We essentially use web components as a templating language to dynamically generate a GraphQL query to Shopify. Then render the data as text nodes inside the web components. This is powerful because the components don't include shadow roots. So you can come with your own HTML and CSS.
Most web component libraries are opinionated about design, and give you many CSS custom properties or CSS parts to customize. We tried really hard to invert that, and instead give you the design control. Most of our web components just produce a text node, with no shadow root!
There's a few exceptions, like the cart for example, where it's easier to just have an out of the box component that does it all for you `<shopify-cart>`. Though...you can actually build the entire cart component with the lower level primitives!
This looks great, glad to see this project and congrats on the launch. Having said that, how does this project fit in with the Shopify Hydrogen effort using Remix / React? There seems to be an ever growing number of ways to build a shopify storefront these days (ie, native templates, remix/hydrogen, web components, Shopify JS Buy SDK, etc.) so it's not clear what technology to "bet on" from a developer perspective.
Separately, nice touch adding the refined LLM instructions, this looks like a nice pattern for other UI frameworks to follow.
I'm a big fan of web components, and this seems like a very cool project. I'm curious about how it fits into the broader frontend ethos at Shopify. I remember the Shopify team being one of the earliest proponents of React Server Components, for example. Is the team still working in that direction as well, or does this represent a new direction org-wide?
I'm also on the hydrogen team. Today we also shipped support for Hydrogen on React Router 7, which has experimental support for RSC: https://remix.run/blog/rsc-preview
Awesome! I appreciate all the open work your team does. A couple years ago, I was staffed on a project that was adopting RSC super early on, and I vividly remember crawling through Shopify blogs/code as one of the few solid resources available.
I'm excited to see more Web Component libraries in the wild eschewing the Shadow DOM. I don't think enough developers have yet caught the message that the Shadow DOM is optional and Web Components are simpler and especially simpler to style if they skip it.
How are these order annotated in Shopify admin? Thinking specifically about various types of partnerships? Could a flow automation be set up to: pay commission (for the influencer model), pay inverse wholesale pricing (for dropshippers), etc.
This seems super powerful. Would you recommend that an app developer who is creating App Blocks for PLPs (Search, Collections, etc.) use these new Web Components instead of building everything themselves?
This is primarily for embedding in 3p sites, Shopify already has liquid for hosted storefronts. As for search and collections, we don't quite yet have support for search and filters. Though we do support pagination.
I like Remix's paradigm of waiting to stream until the primary content is rendered and available, and then only streaming secondary content. So for example, on an e-commerce product page, all the markup representing the product would not stream. Secondary content like related products would. This allows you to 500 error if the primary content fails rendering for one reason or another. And if the secondary content fails to render during streaming, you can easily hide the content or render a placeholder.
reply