lukeed / freshie Goto Github PK

View Code? Open in Web Editor NEW

153.0 153.0 2.0 218 KB

(WIP) A fresh take on building universal applications with support for pluggable frontends and backends.

License: MIT License

JavaScript 44.59% TypeScript 54.87% Svelte 0.54%

freshie's People

Contributors

Stargazers

Watchers

Forkers

ph4ntomiki lgs

freshie's Issues

Add `freshie/request` import

Much like freshie/router -> navaid, re-export httpie as freshie/request or freshie/http -- no changes.

Benefit is that it'll include a universal HTTP client regardless of the SSR choice. The resolve.mainFields are already configured correctly to enable this.

Finally, if you don't use freshie/request, it won't be included at all. There are no internal assumptions made about what/how you're preloading. Opt-in usage would look like this:

import { send } from 'freshie/request';

export async function preload(req, context) {
  let res = await send('GET', '...', ...);
  return { ... }
}

See httpie@next for available methods

Another benefit to this is that because httpie throws (normalized) errors on 4xx responses, you don't have to deal with preload errors by default~! Your 4xx or xxx error template will automatically step in and send the correct error output. However, if you don't want this, you just handle the error manually, as you normally would (and can't avoid in other frameworks) anyway:

import { send } from 'freshie/request';

export async function preload(req, context) {
  try {
    let res = await send('GET', '...', '...');
    return { success: true };
  } catch (err) {
    // send different props to current view
    // instead of deferring to Error page output
    return { success: false };
  }
}

Documentation

lol

Scaffolding

Offer a freshie new that asks a series of prompts (like pwa init) to create a new project.
Should try to make it work as npm init freshie too somehow.

package: ssr.netlify

Much like ssr.vercel – this might be able to get away with reusing/reexporting the ssr.lambda code, but it has to deal with a config file(s):

# netlfy.toml
# needs testing
[build]
  functions = "build/server"

There's also Edge Handlers coming soon(?). Haven't got my hands on them yet, but will need to be its own package, since it has more of a Cloudflare Worker API than a Lambda API.
Maybe ssr.netlify.edge ?

Question: Freshie vs X

Hi, I'm coming here straight after watching your very interesting talk and given that documentation is still a WIP I'd very much appreciate a small description of what your project's big picture goal is here (since I know it's a WIP so the current state is not representative of your vision). I think the easiest way would be to outline the differences with other similar projects I've seen:

Few "competitors":

SvelteKit

Given that SvelteKit is said to be available SOON^TM, do you think what you're trying to achieve with freshie (built-in Cloudflare Workers routing support) will be possible to implement with SvelteKit's adapter API? Do you see freshie supporting Svelte after SvelteKit launches still?
fab

From skimming the README I'm assuming the projects are very similar, but freshie actually supports Svelte SSR?

Since my knowledge is very superficial, I'm asking to learn more as the concept of Svelte + Cloudflare Workers is very appealing. I hope this issue can be helpful to others visiting the repo who are also both interested and confused at the same time.

package: ui.react

Copy ui.preact but with React-specific alterations.
Wait until ui.preact is done to reduce surface area for changes

Allow HTML templating via UI library

Right now, only src/index.html is used as the HTML template. This is used in both client and server outputs.

An early wishlist-item was to allow the option for index.html.svelte when using Svelte or index.html.tsx when using Preact/React, for example. These would include the full <html .../> markup, with freshie only auto-prepending the doctype line 😆

Something like this might unlock a better/opinionated freshie system for dealing with meta tags and <title/>, for instance, because not all UI libraries have those abilities built-in like Svelte does. One possibility could be that any context.$ssr object properties would be accessible to this HTML component as render props.

Another thing – index.html.{extn} is just a special/top-level _layout.{extn} file. This means that it can have its own preload function too (user authentication, session data, etc).

The trick thing here is that layout files can only have 1 <slot/> / props.children placement. This makes injecting documeny.head vs document.body content difficult, especially since in the JSX-world, you can't dangerouslySetInnerHTML on a fragment, and you don't necessarily want to setHTML on the head or body outright either. Easy to workaround for body content, but not easy for head.

package: ssr.vercel

May be able to re-export the ssr.lambda code, but still need an additional layer to write/manage config.
#3 (comment)

package: ssr.lambda

SSR compile target for AWS Lambda and Lambda@Edge. (I think same code can execute?)

Follows & awaits ssr.node's file-serving vs using-a-bucket options (TODO).

Maybe add middleware export for custom Lambda servers?

Synchronize non-external HTML assets with `publicPath` value

As part of the HTML build step, look at any asset path that is not ^(https?:)?\/\/ and update it so that it's led with the desired publicPath prefix.

Safe to do with asset paths like href="/styles.css"" since that's assuming root-resolver.
Less safe to manipulate href="styles.css" since that may need to be a location-based resolver, but I think it's okay for freshie to say that, as the root HTML template, it should only be absolute URLs... since that template is/can be used to render any page.

Dev Server

Build & start the server & client dev-server(s) during development.

Should run both on the same port. The CLI logs/output should be clear without being noisy.

Logic is already in place to force ssr.node attachment during development (unless --no-ssr is provided).
If --no-ssr is provided, still need to run a custom http server that wraps sirv, which will provide file-serving with additional ability communicate with client as needed (eg, basic location.reload tasks).

HMR would be nice, but not needed immediately. That'll be its own issue.

Error

Hi Luke,

I'm getting this error for my cloudflare worker:

Error: Something went wrong! Status: 400 Bad Request, Details {
"result": null,
"success": false,
"errors": [
{
"code": 10021,
"message": "Uncaught Error: Some functionality, such as asynchronous I/O, timeouts, and generating random values, can only be performed while handling a request.\n at line 1 in t\n at line 1 in n\n at line 1 in wake\n at line 1 in Qt\n at line 1 in Wt\n at line 1\n at line 1 in registerPlugin\n at line 1\n at line 1 in n\n at line 1\n"
}
],
"messages": []
}

Any idea what this is?

Thanks

package: ssr.function

SSR compile target for GCP Functions.

Follows & awaits ssr.node's file-serving vs using-a-bucket options (TODO).

Maybe add middleware export for custom servers?

Redirects

Should be as simple as modifying the context within a preload function:

export function preload(req, context) {
  context.redirect = 'https://new.location';
  context.status = 301; // 302 default
}

The trigger is the redirect key, not the status code value!
Relative paths will be resolved from the current req.url.

Can be fulfilled on client-side too, except status change.
This would use a history.replaceState when context.redirect exists.

Error Pages

Add good-looking error pages for each ui package.
Should just be a generic error page that shows stack traces in development.

This issue is not about error pages matching logic – that's been implemented by 8e8feaa already.

Cannot read property 'startsWith' of undefined

On build I'm getting this error:

[freshie] TypeError: Cannot read property 'startsWith' of undefined
at /node_modules/freshie/build/index.js:1:3258