> We are also very excited about D1 as a way to bring a subset of data closer to users in order to deliver faster experiences. We hope this will be a way to bring the benefit of edge computing to larger organisations who cannot simply rearchitect everything to run on Workers.
Yeah, so you can always opt-in to strong consistency by transferring execution to the primary (see the "Embedded Compute" section of the blog). Then it's pretty much exactly the same as a DO.
Yes, which is why Pages has some dedicated logic to help preserve assets that were "seen in the last version now gone". Unfortunately, the "cache everything" setting at the CDN overrides that. We should probably be clearer about that in the docs, and potentially we could autodetect that setting when you register your custom domain, hmmm...
I have not! It was never such a pressing issue that I investiaged a dedicated solution. But given that we're already using Cloudflare, and that this is a solution to a much bigger problem (global coordination + actual storage), but it works really nicely for our smaller usage, it felt like a nice way to dip a toe into this new model.
Beta invites are definitely flowing now, but I'd recommend pinging someone on Twitter or elsewhere with a quick description of what you're going to build. I think they had so many signups they're worried about opening the floodgates, but on a case-by-case basis there's plenty of room. Maybe?
We are taking things slowly. Storing data is a big responsibility. We'll need to test with a small number of users for an extended period (a few months) to work out any reliability issues before we really scale up.
This is more a discussion topic, really interested if someone can explain to me how this email looks legitimate (beyond the information in the replies already)
Yep! I really wanted this, but it's a bit more work. HTML5 canvas has a `measureText` method but it only returns width, so there's a few cases where the text will escape the box. The logic is really simple for now, but I'll hope to improve it in future.
Well, the problem with having foo and foo--bar but not both is that contextual overrides become a problem. Having both of them solves that but clutters things up.
This is a technique to better express your styling intent through markup. Instead of <div class="x x-y z"> you have <div x="y" z> - two namespaces instead of one.
It's trying to ease the problems surrounding contextual overrides.
Having color="red" and other inline styles is a bad design pattern, but AM only superficially resembles it in that it uses attributes. Whether you give an element the attribute of class="nav" or just am-nav, it's accomplishing the same thing: defining that it's a "nav" element for purposes of styling.
Not to be insulting but… are you unable to read text? Because the problem (which has nothing to do with visual clutter and has to do with modularity and contextual overrides) is explained from the third section "Contextual overrides".
You can definitely do this, though I think "data-am-" is better to avoid conflicts. React ignores unexpected attributes at the moment, but can't forever with Custom Elements (since it can't know what valid attributes for new elements are).
I wouldn't completely assume react is going to give on that. In React you can create any custom properties you want to because it's just JS. The problem is how to interop with Web Components and from what I've seen nobody is really interested (rightfully so) in that
Absolutely! The prefix is optional (but recommended). If you're comfortable with data attributes (or, they're required for some reason), thats cool too.
