d3dc/react-flying-saucer

A simple framework built on top of create-react-app for scalable single-page apps with functional react.

react-flying-saucer 🛸

The 👾 aren't in the bikeshed.

 

 

A simple framework built on top of create-react-app for scalable single-page apps with functional react.

Tries to get out of the way by using only next generation JavaScript features and React spacedust.

features:

• 🔗 Compose feature modules as declarative React components

• 🔩 Build functional pipelines with opinionated syntax from babel-preset-techno-babel.

• 📬 Models provide a bite-size abstraction for redux and keep rendering fast with first-class selectors

• 🧱 Write business logic and data sources as plain modules and let dependency injection handle the rest

• 🔋 Batteries included!

  suspense	scoped route trees	dynamic models
  error boundaries	enhanced routing components	shorthand redux bindings
  contextual constants	composable view side-effects	automatic react import

 

 

---

Quick Start

• $npx create-react-flying-saucer app
• $cd app
• $yarn start

---

 

 

Whats in the Box?

react-flying-saucer proposes two declarative react primitives to build your app with. It abstracts outside effects (navigation) and redux state to an "app" container provided by a Mothership. Using React semantics, the mothership declaratively lists the Features that modify and listen to this context - preserving redux state scoping and feature component lazy loading.

<Mothership>
    <FormsProvider>
        <Dashboard path="/dash">
            <GlobalStats />
            <TimerBar />
        </Dashboard>
        <Account
            path="/"
            loggedInView="Dashboard"
        />
    </FormsProvider>
</Mothership>

Simple API

• Mothership
• Features
  • RematchModel
  • FlyingSaucerView

 

• history bindings
• context bindings
• redux bindings

One-touch bootstrap or migrate

• run the latest create-react-app and add react-flying-saucer

$ npx create-react-flying-saucer <project>

• add react-flying-saucer to an existing app bootstrapped with create-react-app

$ cd <project>
$ npx migrate-react-flying-saucer

import aliases

One flying saucer, Two flying saucers

@

A link to the source root of your project.

@@

re-exports everything you need for creating and mounting a feature fleet.

import { $$ } from '@@'
import Sidebar from '@/features/sidebar'

dot files

react-flying-saucer respects any .babelrc and .eslintrc configuration files. Any additional configuration your project needs can be added directly to these files.

 

 

---

Examples

• TodoMVC
• Nesting Features

More Reading

• API
• [WIP]getting started
• [WIP]standalone mothership

Packages

• bundle-react-flying-saucer
  • package a flying saucer app as NPM ready CJS and ESM!
• create-react-flying-saucer
  • create a create-react-app app and then codemod it to outerspace!
• react-flying-saucer
  • npm scripts for a react experience that's out of this world!
• react-mothership
  • react primitives for building stellar apps!

Typescript when?!

As soon as @rematch/rematch fixes its core typings.

react-flying-saucer's Issues

Babel runtime helpers are always ESM

The UMD bundle does not run on some versions of node because of esm syntax in the injected babel helpers.

I believe the rollup script can search babel plugins and change the options?

Template a `jsconfig.json`

We can move to the now pretty standard baseUrl: 'src' most people seem to recommend. Making absolute paths resolve from the source root, removing the need for @ as an alias.

It also gives a more obvious place to expose other aliases like for react-mothership.

rollup-plugin-alias breaking changes

The new 2.0.0 alias plugin for rollup includes vulnerability fixes as well as completely breaking compatibility with the already defined webpack aliases.

We can map aliases to the expected array form or fix the version and force resolution of vuln fixes with package-lock or resolutions.

Better redux patterns

Now that hooks are in react-redux and performant, there's a lot of cases where the regular library makes more sense and it would be less confusing to import from react-redux (or rematch).

The sconnect functionality and useApp* functionality could better integrate with the raw hooks already given to us instead of abstracting them - making redux binding external.

`@babel/runtime` is inserted using the `absoluteRuntime` option

Bundling can throw an error for regenerator due to rollup config when using generators or async functions!

You must set "output.dir" instead of "output.file" when generating multiple chunks.

When using dynamic import() statements, rollup complains about the config options.

Remove built-in placeholder plugin

The babel plugin enabling the _ placeholder clashes with minified code; meaning we can't just blanket add in our babel configuration and even the module forms of packages have to be bundled (bundle-react-flying-saucer).

param.macro is one more import away and provides a cleaner API.

There's something to be said for not having to import the macro - but this appears to be hard to do without another loader.

Bundling blocks hot reloading in mono-repos

Even with modules declared, It forces a workflow of:

1. lerna bootstrap
2. cd
3. npm run start
4. error
5. fix
6. nothing.
7. lerna bootstrap or npm run prepare in a dependency
8. hot reload actually happens

new project template uses old `useProvided`

.babelrc doesn't load import plugin

{
  plugins: [
    "import", {
      "libraryName": "react-use",
      "libraryDirectory": "lib",
      "camel2DashComponentName": false
    }
  ]
}

Remove Rollup and just use Webpack

Rollup is an additional dependency, that has its own set of problems and plugins.

I didn't use Webpack initially, because I just went with what works.

To use Webpack, we have to remove the HTML plugin, and change the inputs/outputs. This doesn't seem like that much work using the craco utils?

Update: and then the bundled code needs to be built in a format that allows the most flexible use - it seems like we would want ESM bundles to let motherships use treeshaking across the fleet

Exiting react-scripts in watch mode does not gracefully restore package.json

Since I switched from using cross-spawn, exiting the process exits the process. This means there's no place for a graceful shutdown. Oops.

Rollup doesn't resolve '.jsx' extension

Rollup's default extensions only include: '.mjs', '.js', '.json', '.node'

An error is thrown when trying to compile the examples.

Most likely won't fix due to #9

Remove implicit functions

Are arrow functions not short enough?

What do we gain by making a breaking syntax change?

Stop re-exporting Router primitives?

We can instead provide hooks or another functional abstraction to resolve named views and pass them to any component.

How does this interact with overriding the <Route /> component?

@babel/register functionality

Instead of --watching, we could expose a require() hook that compiles on the fly...

pros

• no background processes

cons

• require hacking

craco fails when bootstrapped with lerna

When using lerna bootstrap, examples/<project>/node_modules/react-scripts is not created and is instead in the symlinked react-flying-saucer package.

Edit: I'm assuming this is either a yarn bug or just related to symlinks, so this probably also effects pnpm et al.

Bundling silently fails

When bundling pre-0.0.40, errors used to be passed along to the console.

Now, bundling succeeds, but does not emit any files or console output.