Client setup seam: run app code before the generated entry's hydrate (start.clientSetup)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- typescript, vite
- 领域
- build-system, frontend
调研方向
This is a design decision, not a ready-to-code task: the issue asks for a start.clientSetup option or a <ClientEntry /> component, and the maintainers have not chosen between them. Start with the code that generates the client entry and the existing start.instrument server hook, which the issue uses as the model. Done means a maintainer agrees on the API and the generated entry runs the setup module before hydrate.
由索引模型根据 Issue 内容生成。
描述
@solidjs/vite-plugin 3.0.0-next.50, solid-js 2.0.0-rc.15.
The generated client entry calls hydrate straight away, and there is no place for app code that has to run in the browser before hydration. Our real cases:
- Installing a server-function transport wrapper that detects a response from another build (version skew) and reloads. It must be in place before the first render fires the page's reads.
- A request-header hook on that transport, for example a tenant selector header the server functions need.
- Registering the
vite:preloadErrorlistener before any lazy route chunk loads. - Reading a third-party global that a classic
<script>in<body>defines (Telegram'stelegram-web-app.js). Today the generated entry is anasyncmodule in<head>, so its order relative to that script is not guaranteed. #411 / solidjs/solid#4002 fixed hydration itself here, but not setup code that reads globals.
Because of this we keep authored entry-client.tsx / entry-server.tsx pairs only to run three lines before hydrate. That means we also carry the Document + hydrate(…, document) boilerplate that the generated entries would give us.
Suggestion (either works for us):
start.clientSetup: './src/client-setup.ts'. The generated client entry doesawait import(setup)(or a static import placed first) beforehydrate. This mirrorsstart.instrumenton the server.- A
<ClientEntry />component that the document places where it wants (for example at the end of<body>), with the setup module option above.
Option 1 alone would let us delete both authored entries.
- 主要语言
- TypeScript
- 星标
- 522
- 派生
- 73
- 平均合并
- 1 天 5 小时
- 30 天内合并 PR
- 34
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
solidjs/solid-vite-plugin 的其他 Issue
-
Test environment detection doesn't consider Vitest workspaces可能已有人在做 @carloitaben 于 54 天前认领。 未关闭1.x
难度 2/5 1-3 小时 新手友好度 78/100
solidjs/solid-vite-plugin#205 · 1 条评论 · 2 个 reaction ·
维护者通常 1 天内回复
-
难度 3/5 半天 新手友好度 55/100
solidjs/solid-vite-plugin#420 ·
维护者通常 1 天内回复
-
难度 4/5 1-2 天 新手友好度 30/100
solidjs/solid-vite-plugin#418 ·
维护者通常 1 天内回复
-
Dev manifest bridge keeps stale CSS after an edit可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 4/5 3-5 天 新手友好度 34/100
solidjs/solid-vite-plugin#415 ·
维护者通常 1 天内回复
-
Dev manifest loses lazy CSS when imported before HTTP startup可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 4/5 3-5 天 新手友好度 25/100
solidjs/solid-vite-plugin#414 · 1 条评论 ·
维护者通常 1 天内回复
查看 solidjs/solid-vite-plugin 的全部 Issue
相似的 Issue
-
area:ui effort:S enhancement priority:P2
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
QuantumNous/new-api#7839 ·
维护者通常 1 天内回复
-
good first issue maintenance
难度 2/5 1-3 小时 新手友好度 62/100
dark-princezz/stellar-hooks#1010 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
interledger/rhyza#352 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复