bizarre
commented
1 year ago
- doesn't seem to be a way to test server components that utilize async/await (even if they're 'embedded' in a client component)
- more specifically, can't test them in typical jsdom testing-library/react way, as
render()won't accept a future. we could still do e2e-esque tests, where we spin up a http client and check the DOM that way (or even something like cypress). super annoying as i'd love to start building up some basic unit tests, and have even thought about converting all of the server components that fetch to client components but...
Wrote a tiny helper to "patch" async components in place for testing: https://github.com/bizarre/rsc-test-helper. We should be able to start writing more tests w/o having to worry about making everything a "client only" component. Once official support rolls out for this, migrating over should be super easy** (just removing one line of code per test of a async/await SC, could write a codemod to do it to all our tests automatically later.
**: unless there's like a fundamentally different approach to testing server components (which there might be, as they still have to figure out how to let us test pre-hydration states so people can test their Suspense fallbacks?)
jonahseguin
figured i'd make this issue just to track some of the current blockers on the frontend as they're piling up and i don't wanna forget about em.
render()won't accept a future. we could still do e2e-esque tests, where we spin up a http client and check the DOM that way (or even something like cypress). super annoying as i'd love to start building up some basic unit tests, and have even thought about converting all of the server components that fetch to client components but...once above reactedit: lmao,usehook gets implemented, we'll be able to leverage<Suspense></Suspense>for rendering skeletons in client components. if we were to go ahead and hack a way to fetch from client components right now (next.js beta docs show workarounds for this), we wouldn't be able to use<Suspense>in the same way, and migrating once the first class support for promises rfc is implemented might be tedious.useis implemented already, but works pretty wonky and often leads to 'double fetching', but might be good enough to continue. doesn't play well with current testing env either tho.<Suspense>so that switching over later would be easier.<-- this is probs the best way forward negl.cookies()andheaders()are read-only, so we can read the user's theme but we can't actually set itpages/apiroute, but no dice. next.js team says write functionality is otw.standalonenextjs build, so we have to pretty much have the exact samenode_modulesin our prod build as our dev build, app beta still seems to read directly from src files (even followingnext buildandnext start). current workaround in cli is to just clone the entire repo and install deps + build as part of theorbt startcommand. current solution means we don't have to distribute super big docker images, but once standalone gets implemented we can build a pretty small image that will speed up app start time, as docker will already be a hard req due to vm.another big initial blocker was vanilla-extract not working properly, due to how the new next.js app-render works, but was able to do a dirty patch to get it to kind of work.
with all these blockers, it might be worth considering to opt out of the beta and fall back to the traditional
/pages/app. i really love all the cool stuff that's introduced in the beta, but if we stick with it, it'll probably mean writing super janky hacky frontend code in the mean time and a possibly decent-sized re-write in the future when the beta catches up. or, we focus on other parts of orbt, and leave the frontend until the very end, hoping that appDir has caught up by then.cc: @jonahseguin