lucasecdb / casterly Goto Github PK
View Code? Open in Web Editor NEWIsomorphic server rendering library for React
License: MIT License
Isomorphic server rendering library for React
License: MIT License
Currently to declare the routes inside Casterly we must do a dynamic import on the routes.js
file, which is what we use internally to split up the modules into separate bundles and how we collect the information of which route loads which component.
I'd like to change this from instead of using dynamic imports to use a filename convention, like so:
// routes.js
import IndexPage from './pages/index.route.js'
export default [
{
path: '/',
element: <IndexPage prop="hello" />,
},
]
This would also enable us to introduce dynamic generation for routes, such as creating an abstraction on the file system to create static routes (e.g. for a blog or documentation website):
// routes.js
import IndexPage from './pages/index.route.js'
import BlogPostPage from './pages/blog-post.route.js'
export default async () => {
const blogPosts = await getBlogPostsFromFileSystem()
return [
{
path: '/',
element: <IndexPage prop="hello" />,
},
...blogPosts.map(({ slug, content }) => ({
path: `/blog/${slug}`,
element: <BlogPostPage slug={slug} content={content} />,
})),
]
}
Currently we use the following filename convention for determining if a file should be a CSS module vs global CSS:
styles.css
But it is well used in the React community to use the styles.module.css
for CSS modules, and the above filename convention for global CSS modules. For global CSS we are currently using the following:
styles.global.css
We should change this in our configuration to match the expectations of other React frameworks.
a la _error.js
in Next.js
follow-up on #7
Instead of hard-coding the alias paths in the build folder, we should probably read those values from the user tsconfig.json
. Example
When Casterly's own webpack configuration cannot meet the demand, we need to expand it.
For example, add a new babel plugin, add alias, etc.
Similar to next.js, we need a configuration file, for example: casterly.config.js
.
const path = require("path");
module.exports = {
webpack: (config, { isServer, webpack }) =>{
config.resolve.alias['@components'] = path.resolve(__dirname,"src/components");
config.resolve.alias['@utils'] = path.resolve(__dirname,"src/utils");
return config;
},
devServer:{
port: 8081
}
}
Sample code:
// src/IndexPage.jsx
export default ({ user }) => {
return (
<>
<p>Hello world!</p>
<div>{ user?.name }</div>
</>
)
}
export const getInitialProps = async () =>{
const user = await fetch(url).then(res=>res.json());
return {
user
}
}
// routes.js
export default [
{
component: () => import('./IndexPage'),
path: '/',
},
]
The getInitialProps function is executed when the server is rendering and switching routes.
Hope that the library can be used in production as soon as possible.
Currently, there is not way to create a fallback route with a 404 fallback page that sets the correct status code on the response.
The only workaround currently is to create a catch-all route, but that will return a 200 status code to the client instead of the correct 404. The solution should be to include a new export in the routes.js
file which should be used when no other route is found.
// routes.js
export const notFound = {
component: () => import('./not-found-page.js')
}
export default [
// ...
]
follow-up on #7
We should do the server render and client hydration, instead of relying on a function being exported on the index file from the user's app. Would need to change this line and probably use this code when rendering on the server, and include some snippet like this to render on the client.
We could probably do something like what Next.js does, and add a client.js
file, with the boilerplate for the client, and add that to webpack so it compiles the file with the app's code.
would be nice to also add a data-fetching example
follow-up on #7
I tried this library and it is great.
But I have a problem with code splitting.
I use @loadable/component:
import React from 'react'
import loadable from '@loadable/component'
// import OtherPage from './OtherPage'
import App from './index'
const OtherPage = loadable(() => import('./OtherPage'))
export default [
{
element: <App />,
path: '/',
},
{
element: <OtherPage />,
path: '/other-page',
},
]
It executes normally, but it is not server-side rendering, but client-side rendering.
It seems that until the server responds, the dynamic component OtherPage still does not render
The server's response is similar to the following result:
<html>
<head>
<title>My App</title>
</head>
<body>
<div id="root"> </div>
<script src="static/js/main.js"></script>
<script src="static/js/runtime-main.js"></script>
<script src="static/js/vendors.js"></script>
</body>
</html>
Search engines cannot capture complete html pages, making seo meaningless.
I don't know how to solve this problem
A declarative, efficient, and flexible JavaScript library for building user interfaces.
đ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. đđđ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google â¤ī¸ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.