Given we want to be able to provide better integration with existing JS frameworks to provide guided stories, the following blockers for NextJS should be (re-)assessed:
- Exotic filenames: Right now, NextJS heavily relies on exotic filenames / duplicated filenames, which requires ReScript users to re-export ReScript components in shim JS files in the
pages and app directoy
- Shared props for getStaticProps / default export: Previously, one had to fall back to
let default = (props) => {} just to be able to share the props between the consuming component and getServerProps etc. ... I think this should be solved with @mununki's new JSX 4, which should be able to provide a custom prop type to a @react.component decorator
- Props serialization with undefined props: Previously, serializing props from
getServerProps etc. will cause the frontend to break, because foo: undefined is not valid JSON (it gets passed as a string and then JSON.parsed). This should be fixed with optional attributes (e.g. {foo ?: string})
- Function level directives (
"use server";): As for right now, it is only possible to provide those directives on the module level. We'd need a way to maintain directives on a JS function level
(Please note: The provided list is kept short, details should be refined in linked issues if there's any need to solve a problem)
Given we want to be able to provide better integration with existing JS frameworks to provide guided stories, the following blockers for NextJS should be (re-)assessed:
pagesandappdirectoylet default = (props) => {}just to be able to share thepropsbetween the consuming component andgetServerPropsetc. ... I think this should be solved with @mununki's new JSX 4, which should be able to provide a custom prop type to a@react.componentdecoratorgetServerPropsetc. will cause the frontend to break, becausefoo: undefinedis not valid JSON (it gets passed as a string and thenJSON.parsed). This should be fixed with optional attributes (e.g.{foo ?: string})"use server";): As for right now, it is only possible to provide those directives on the module level. We'd need a way to maintain directives on a JS function level(Please note: The provided list is kept short, details should be refined in linked issues if there's any need to solve a problem)