@adland/embed 0.2.3 → 0.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +59 -0
- package/dist/adland-farcaster.js +55 -55
- package/dist/adland-farcaster.js.map +1 -1
- package/dist/adland.js +44 -44
- package/dist/adland.js.map +1 -1
- package/dist/index.cjs +24 -6
- package/dist/index.cjs.map +1 -1
- package/dist/index.js +25 -7
- package/dist/index.js.map +1 -1
- package/package.json +3 -3
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,64 @@
|
|
|
1
1
|
# @adland/embed
|
|
2
2
|
|
|
3
|
+
## 0.4.0
|
|
4
|
+
|
|
5
|
+
### Minor Changes
|
|
6
|
+
|
|
7
|
+
- e572ef2: `<adland-slot>` no longer reads off a public RPC by default.
|
|
8
|
+
|
|
9
|
+
The element calls `@adland/react`'s `createReadClient`, so it inherits that
|
|
10
|
+
package's new transport: adland's cached read endpoint first, the chain's public
|
|
11
|
+
RPC behind it. Previously it went straight to `https://mainnet.base.org`, which
|
|
12
|
+
Base documents as "rate-limited and not suitable for production traffic".
|
|
13
|
+
|
|
14
|
+
Written as its own entry rather than left to the automatic dependency bump. The
|
|
15
|
+
CDN bundle inlines `@adland/react`, so a patch that said only "updated
|
|
16
|
+
dependencies" would ship a real change in where every embed's reads go, to the
|
|
17
|
+
consumers least able to notice — script-tag users who never see a lockfile.
|
|
18
|
+
|
|
19
|
+
`rpc-url` on the element still overrides both, unchanged:
|
|
20
|
+
|
|
21
|
+
<adland-slot slot-key="adland-1" rpc-url="https://my-node.example"></adland-slot>
|
|
22
|
+
|
|
23
|
+
Script-tag users are pinned to a published version through jsdelivr
|
|
24
|
+
(`@adland/embed@<version>/dist/adland.js`), so they get this when the package is
|
|
25
|
+
published AND the `EMBED_VERSION` the docs hand out is bumped — not before.
|
|
26
|
+
|
|
27
|
+
### Patch Changes
|
|
28
|
+
|
|
29
|
+
- Updated dependencies [e572ef2]
|
|
30
|
+
- @adland/react@0.24.0
|
|
31
|
+
|
|
32
|
+
## 0.3.0
|
|
33
|
+
|
|
34
|
+
### Minor Changes
|
|
35
|
+
|
|
36
|
+
- 7899811: `<adland-slot slot-key="adland-1">` — name the space instead of addressing it.
|
|
37
|
+
|
|
38
|
+
The custom element could only take a `slot` address, which is the one thing in an
|
|
39
|
+
embed nobody can ever change: redeploy the slot and every page carrying it shows
|
|
40
|
+
a dead space forever. `slot-key` is resolved through the metadata module when the
|
|
41
|
+
ad renders, in a single `eth_call`, so the slot behind the name stays ours to
|
|
42
|
+
move.
|
|
43
|
+
|
|
44
|
+
- `slot` still wins when both are set — pinning an address remains a way to opt
|
|
45
|
+
out of trusting the registry.
|
|
46
|
+
- `ad-module` overrides the module the name resolves through, for chains the
|
|
47
|
+
default map has never heard of.
|
|
48
|
+
- The resolved address is threaded to the impression beacon and the empty-slot
|
|
49
|
+
CTA. Both read the `slot` attribute, so a name-only embed would have recorded
|
|
50
|
+
nothing and linked nowhere — silently, since neither path errors.
|
|
51
|
+
|
|
52
|
+
The same fix lands in `@adland/react`: `<Ad slotKey>` built no read client and
|
|
53
|
+
skipped tracking entirely, because both were gated on `slot` being present.
|
|
54
|
+
|
|
55
|
+
### Patch Changes
|
|
56
|
+
|
|
57
|
+
- Updated dependencies [7899811]
|
|
58
|
+
- Updated dependencies [7899811]
|
|
59
|
+
- @adland/data@0.20.0
|
|
60
|
+
- @adland/react@0.23.1
|
|
61
|
+
|
|
3
62
|
## 0.2.3
|
|
4
63
|
|
|
5
64
|
### Patch Changes
|