RFC: Prototyping workfow via `sku proto`

[Mark Dalgleish]

Summary

Prototyping workflow via a sku proto command, inspired by kyt's proto command.

Motivation

Sometimes developers and designers want to quickly throw together some components to kick off a design process. The mature our style guide gets, the more efficient it is to prototype in the browser with prefab components instead of using design tools that are heavily disconnected from the underlying medium. To ease this process, it seems like a good idea to make prototyping a first class workflow in sku.

Detailed design

First of all, in terms of naming, I wanted to expand the name to "prototype", but quickly realised this causes issues once you're in JavaScript and "prototype" means something very different, so "proto" works well enough as a shorthand.

The entry point from a user's perspective would be the sku proto command, but probably via npm scripts (npm run proto).

This would necessitate the introduction of another entry point, which means your sku config would change like this:

module.exports = {
  entry: {
    client: 'src/client.js',
+   proto: 'src/proto.js',
    render: 'src/render.js'
  }
};

We could potentially support this in zero-config mode by using src/proto.js as the default value, similar to how we handle src/client.js and src/render.js.

I imagine this would inherit all the same settings as running sku start in terms of environment variables, etc.

To keep things simple, the code in proto.js would be purely client-side. I'm thinking you'll have no access to the underlying index.html (probably generated with html-webpack-plugin.

Running sku proto would open the page in a browser with hot reloading enabled, similar to sku start.

How We Teach This

I think we'd introduce this early in the docs, since it would also be used early in the design phase. Ideally we'll have some sort of sku init step built out at some point, which would ease adoption of this workflow.

A big focus on this feature would be highlighting that it's for both developers and designers. Again, the future introduction of sku init would really complement our work in this regard.

Drawbacks

• Adds config complexity, requiring yet another entry point (we've got server rendering on the way, so we'll be up to four potential options)
• Makes the internals of sku quite a bit more complicated
• Not everyone will need a prototyping workflow

Alternatives

We could avoid a sku proto command entirely, and just force people to create separate sku projects when they want to prototype. We could instead create a prototyping boilerplate one of the options in a future sku init script.

Unresolved questions

Does prototyping deserve to be a first-class part of sku? What makes prototyping a special case? Are there specific features you'd want while prototyping but not while building your app?

Should you be able to server render a prototype? If so, why?

[Jye Nicolson]

What do you envision the lifecycle of the proto code being? What's the advantage of doing this in a consuming app rather than just spinning off a prototype branch? (given that you probably still need to do that?)

[Mark Dalgleish]

Yeah, definitely starting to lean towards the latter (writing out this RFC helped me start to realise this, tbh)

[Mark Dalgleish]

After thinking this over and discussing with a few people, I'm closing this RFC. Instead of making prototypes a first class citizen in sku, we'll probably focus instead on tools for generating new projects. In that context we may introduce a boilerplate specifically for prototyping, but we'll see how it goes.