feat(baseline): add link to developer-signals repo#1212
Conversation
|
Failures are unrelated, see: #1213 |
|
2937721 was deployed to: https://fred-pr1212.review.mdn.allizom.net/ |
| /** @type {Record<string, { url: string, votes: number }>} */ | ||
| let signalsData = {}; | ||
|
|
||
| try { | ||
| const signalsRes = await fetch( | ||
| "https://web-platform-dx.github.io/developer-signals/web-features-signals.json", | ||
| ); | ||
| signalsData = await signalsRes.json(); | ||
| } catch { | ||
| // noop | ||
| } |
There was a problem hiding this comment.
@caugner this obviously feels wrong - and was intended as a temporary hack to get a prorotype of this up - but the more I think about it, the less I'm sure we shouldn't be doing it
What's, actually, the problem with fred making API calls at build time? Perhaps we want it to be stateless so we can easily render in the cloud function in the future... but really the only reason we'd want to do that is to do API calls at render time and dynamically update things without needing a full rebuild.
Maybe there should be a more formal contract here, rather than allowing components to fire off API calls willy nilly. Perhaps we define and run the calls at a higher level and pass them down through the context.
But I think there's something appealing to not being tied to rari for fetching data we only need in fred.
Thoughts? Hot takes welcome.
There was a problem hiding this comment.
The question maybe is if the information we fetch should also be included in the index.json. If it doesn't need to, then fetching might be fine. IIRC we also already fetch GitHub issues directly from the client on the community page, but obviously we wouldn't want to do this on every page. I think we want to be careful and resilient, so that rendering doesn't fail if the format changes in an incompatible way.
There was a problem hiding this comment.
We fetch the github issues client-side, whereas this would be "server"-side.
I think we want to be careful and resilient, so that rendering doesn't fail if the format changes in an incompatible way.
I guess that depends: if this is integrated in rari, and the format changes in an incompatible way, we would fail the build by default.
FWIW: I'm adding this to rari for the moment, because I'd like to generate a list of pages on which this will appear: and it's far easier to parse a tree of index.jsons than, I'm not sure, grep for the existence of these links in the rendered html files or something?
2 participants
Depends on, so opening as draft mdn/rari#473. Design/copy also not final, needs discussion with content and internally.