Comments (8)
Thank you for the deep dive. I would honestly love some other brains to hop in on this project since it seems to be generating a lot of interest!
I'm sure the "head scratching" spots are the same ones I'm wrestling with—the dev/build time indirection is a major issue that needs to be addressed. Snowpack didn't expose an actual SSR runtime when I wrote this, but now that it does this should be unblocked.
I need to push up my upcoming 1.1.0 changes, but I'll tag you and would love your eyes on them.
from microsite.
generating a lot of interest
Obviously I’ve already been looking at it but in case you’re not aware Microsite is prominently linked at least a couple places on Snowpack’s post-3.0 release materials. I’m sure that’s driving some traffic.
I'm sure the "head scratching" spots are the same ones I'm wrestling with—the dev/build time indirection is a major issue that needs to be addressed. Snowpack didn't expose an actual SSR runtime when I wrote this, but now that it does this should be unblocked.
Yeah, this is an area I’m particularly interested in because as far as I’m aware no existing tooling in the space specifically caters to separate client vs server/static builds, but it does look like Snowpack is going that way which is exciting. A lot of the techniques I’ve seen in your approach mirror those I’ve been trying myself (just to with less full familiarity with the tooling than I have now): a whole lot of substitution based on target environment.
I need to push up my upcoming 1.1.0 changes, but I'll tag you and would love your eyes on them.
That would be awesome. I’d really love to actually get a proof of concept of my first build up (it’s not my whole project, just a temp page so I can call my tech stack spike done, I’m happy to work on unstable APIs in the meantime) just to unblock my brain from the question of what tools I plan on using.
from microsite.
I'm looking back at this issue. Am I missing something or will this be addressed in #94 with the use of a custom src/_document.tsx
file? I'd love to take a look at your attempt to make sure we're covering this.
Note that I still have to implement custom _document
support in dev mode, which requires dev mode SSR, which is waiting on @prefresh/snowpack
to be released.
from microsite.
Sorry, I'll clarify. The issue, at least as I've experienced it with 1.1.0-next.2/1.1.0-next.3 is that, while the Snowpack config is applied and works more or less as expected, the build process also imports pages to collect getStaticProps
& getStaticPaths
data from the staging path, where the build hasn't yet occurred. Anything in those import paths which may be compiled out is still in place and run on import.
For example with Linaria, the runtime for css
calls is compiled to a class name string, and the runtime for styled
is compiled out to a plain component with its class name applied as a prop. In both cases, before compilation those functions will throw if called at runtime, warning that you have forgotten the compile step. (Aside: in my opinion this isn't a wonderful DX, and it's part of why I went and looked at other libraries and settled on Fela).
It may be as simple as importing from SSR_DIR
rather than STAGING_DIR
(if you can trust that whatever user-supplied config isn't mangling the names you want to import), or as complex as running fetchRouteData
within a Snowpack or Rollup plugin in the same build pass (which seems safer for sure).
from microsite.
I will say as a matter of opinion, I think it would be a good thing for DX generally if the entire dev and build flows were packaged as Snowpack plugins, or each as a set of plugins if there's interest in picking and choosing certain behaviors, or if flexibility with ordering of build steps is needed. That would probably eliminate the need for Microsite to muck around with a user's custom config at all, and the dev and build flow would be a bit more clear. But I'm not sure how feasible this would be, at least without some significant rework.
from microsite.
Ah OK that makes more sense! Thank you. I think I have a solution for you.
As an aside,
STAGING_DIR
is actually the Snowpack output, so the user's config should be applied to that.SSR_DIR
is generated from that output by applying Microsite'srollup
magic.
I think this has something to do with your setup, which I'm happy to take a look at if you're still getting tripped up. Are you trying to hook into the server-rendered CSS in getStaticProps
? There's obviously no documentation on this yet, so I totally get why that approach makes sense, but I don't think that will work (or that we want it to work).
The place for this would be in a custom src/_document.tsx
file. You could use defineDocument
to hook into the rendering process. prepare
will be run for each page, so you can handle any global, apply-to-every-single-page logic like this.
import { Html, Head, Main, MicrositeScript, defineDocument } from 'microsite/document';
const MyDocument = ({ css }) => {
return (
<Html>
<Head>
<style data-server-styles dangerouslySetInnerHTML={{ __html: css }} />
</Head>
<body>
<Main />
<MicrositeScript />
</body>
</Html>
);
};
export default defineDocument(MyDocument, {
async prepare({ renderPage }) {
const docProps = await renderPage();
const css = collectServerStyles(); /* the SSR method from your library */
return { ...docProps, css: };
}
});
To explain why we shouldn't support this in getStaticProps
or getStaticPaths
:
Those methods should be isolated functions that don't have access to the Component they are rendering. This follows Next.js's Data Fetching model for familiarity and also keeps the door open for potential server-side/JIT rendering in the future. The more tangible reason fetchRouteData
is run out-of-band with the actual static generation is to maximize concurrency and keep builds as fast as possible. Fetching Route Data has the potential to be a huge bottleneck, so we want to kick it off as soon as possible.
from microsite.
I will say as a matter of opinion, I think it would be a good thing for DX generally if the entire dev and build flows were packaged as Snowpack plugins
I don't disagree with this at all—I'll have to explore this idea. At the time of writing, Snowpack didn't offer getServerRuntime
, but I think we might be able to accomplish this through that. Microsite's build could potentially be relegated to the plugin's optimize
step. I opened #99 to keep this in mind.
from microsite.
I think this has something to do with your setup, which I'm happy to take a look at if you're still getting tripped up.
That's what I thought too, reading through the build. It's really baffling to me why I was getting correct Linaria behavior (it was in fact actually compiling away the runtime) but then it would still hit the runtime in fetchRouteData
. I honestly gave up on this but I know you're tracking CSS-in-JS support generally so maybe we can take a look together after I get a little momentum both on my personal site and here in Microsite.
Are you trying to hook into the server-rendered CSS in getStaticProps?
Actually no, I was running Linaria's Babel/Rollup plugins at build, which is supposed to extract a static CSS file and add it to the page as a link
. I tried a zillion different approaches and eventually gave up and accepted the sunk cost. So far I haven't even used getStatic*
in my little spike project (though I will for my real project).
The place for this would be in a custom src/_document.tsx file. You could use defineDocument to hook into the rendering process. prepare will be run for each page, so you can handle any global, apply-to-every-single-page logic like this.
That's definitely something I'm incorporating now for a variety of reasons, and will almost certainly be a part of my solution for extracting styles.
// ... <style data-server-styles dangerouslySetInnerHTML={{ __html: css }} /> // ...
I'm actually a weirdo 😜 who prefers a single site-wide CSS file applied with link
. I'm not even fully convinced of "critical style extraction".
To explain why we shouldn't support this in getStaticProps or getStaticPaths [...]
Oh I totally agree with all of this. And I quite appreciate the fact that the API and behavior match Next.js (and this appears to be turning into a somewhat de facto standard across SSGs).
from microsite.
Related Issues (20)
- Remove defer from inline scripts HOT 3
- Move `microsite-templates` into this repo HOT 1
- Doesn't do the thing 🙃 HOT 3
- Partial hydration causes Preact to be fetched twice HOT 10
- production build fails when CSS module is imported on multiple pages HOT 2
- getStaticProps + node builtins + dev server fails HOT 1
- Preact import regex matches too much HOT 2
- Preact CDN lookup fails for non-hardcoded submodules HOT 1
- Enhancement: Support SSR-able components as props for hydrated components HOT 7
- getStaticPaths uses module’s path when returning params object HOT 1
- [RFC] Built-in Markdown/MDX Support HOT 2
- Dynamic routes won't work in dev mode HOT 4
- Hydrated component isn't initialized in prod builds when it is exported/imported under a name different from the name of the component it decorates HOT 6
- Make withHydrate a no-op when nested rather than an error
- Hydration fails with nested props arrays/objects HOT 7
- Build fails with "Error: You must supply options.input to rollup"
- import.meta.env.SSR is true on the client HOT 1
- Preact modules are loaded with `modulepreload` even if they're not used
- dev server fails to load fetch HOT 1
- Add SCSS/SASS support?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from microsite.