Roadmap

General roadmap for upcoming ReactQL features, and a tentative order they’ll be approached.

Feel free to suggest any features you’d like to see in this thread, and they’ll be considered for inclusion.

Note: The raison d’être of ReactQL is to remain a lightweight, general purpose starter kit for building GraphQL-backed front-ends. Niche features should generally be built on top of the kit, rather than wind up in core. But all sensible use-cases and suggestions will be considered.

Soon:

• ReactQL CLI, installed via npm i -g. Easily spawn a new project with reactql new instead of manual git clones and tidy-up. Will make it easier to version the kit and distribute the start-up code offline.

• Yarn building. Should speed up equivalent npm installs of modules.

• Better SASS/LESS imports. The loader config needs tweaking to standardise import styles between different CSS loaders. Could also do with a better strategy for importing third-party classes globally or locally, for better framework support – Semantic, Bootstrap 4, etc.

• Typescript option.

• Development web server, that restarts automatically on code changes, alongside the existing hot-code reload Webpack dev server.

• Deterministic versioning- have one kit version per CLI installation, which can alert when there’s an update available, so there are no surprises when creating a new project and finding that the kit has changed.

• Helper component for code splitting and loading screens a la #3, along with updated docs.

• Video guides & articles in docs for common use cases and code tutorials on how to use GraphQL in practice like how to build a GraphQL server on top of the kit, etc.

• ~i18n / l10n internationalisation / localisation support~ (After some testing, it’s clear that i18n is far too opinionated to suit every use case-- libs, translation loading strategies, etc will differ widely per project. I’ll save this one for a future ‘examples’ kit)

Future / tentative

• Progressive web app features (#40)

• Mobile/desktop framework support, for creating Cordova/Phonegap/Electron apps.

Example kits

• i18n / internationalisation. (Originally, I wanted this in core, but there are far too many ways this could be done. An example starter is probably best.)

• GraphQL subscription examples and patterns. Possible web socket proxy via the built-in server? (needs more thought)

[leebenson]

Alright guys, a long time coming, but I released 3.0.0 today.

After much back and forth on the approach, I decided to stick to the original ethos, which is offering ReactQL purely as a universal, front-end starter kit rather than a ‘framework’ with a bunch of abstractions vs. making direct changes to the code. I didn’t/don’t want to hide any details of what the kit is doing behind a NPM module, or make a distinction between ReactQL and userland code.

Instead, you can just clone the repo, and start coding.

The GraphQL server functionality has been ripped out. That’s really easy to add back in if you need it, but I’d generally recommend the server being separate anyway. When you’re connecting to databases, third-party APIs, it’s easy to bloat the front-end with a bunch of stuff that’s really the domain of a separate server, so I’ve kept this kit lean and focused on one goal: Rendering GraphQL in React.

I’ve also updated the stack to the latest on offer: React 16.4, Apollo 2.0, Webpack 4. Styled Components has been added, with an included helper lib that makes theming really easy. SASS/LESS/external .css imports are still supported - you can now use both.

The build process has undergone a major overhaul with Webpack 4. Gone are the overly entwined Webpack config files. Now, the server entry point returns React middleware, and it’s from that point that the resulting server.js file is built. That allows the Koa web server to be spawned in Javascript and just add the Webpack built file as middleware, dramatically cutting down on what needs to be built on the server.

It also made it much simpler to add hot-code reloading to Koa, so now we have full SSR in both development and production! What’s more, the server fully restarts on all code changes, so you get both browser patching and immediate SSR updates on refresh. Both dev and production spawn on port 3000 now, too, making it trivial to switch between environments via the command line and not have to remember a bunch of ports.

I’ve performed a long-awaited transition to Typescript. The whole kit is written in Typescript now. I realise there are users who might Flow, or even just vanilla JS. That’s fine, but I had to make a choice, and Typescript has - for me, at least - provided the best developer experience of any, especially when paired with Visual Studio Code. I feel it offers the more comprehensive typing whilst also (for the most part) being helpful enough to pick up goofs, without getting in the way.

If you’d prefer vanilla JS, you should just be able to import .js files (instead of .ts(x)) and it should just work. I haven’t tested this comprehensively though, so YMMV. File an issue if you find anything that’s not quite right.

Finally, in case you hadn’t noticed, there’s no longer a ReactQL CLI. The new home for this kit is https://github.com/leebenson/reactql. Since we’re back to the original ethos of this being a starter kit, I wanted to make it very clear that getting started literally just means cloning the repo and laying down some code. The CLI, IMO, made this feel more ‘frameworky’ and didn’t offer any real advantage. So it’s gone.

I’d welcome any feedback on the new approach, and kit in general. If you spot any issues, as always, just file an issue.

The motivation for this new kit was to squarely use this as my de facto front-end in a number of client and personal projects I’ve been working on. Clearly, the previous version of ReactQL was showing its age (over half a year since I’d made any significant changes, which is a lifetime with this fast-moving GraphQL stack…). There were a few things I wasn’t happy about, like straddling between it being a starter kit and a ‘real’ framework, and security issues started cropping up in old pieces of the stack.

This version has been re-written from the ground up. I hope you find it useful.

[leebenson]

Just a heads-up that the first version of the CLI has now been released with the 2.0.0 tag.

Quick start

Install the ReactQL CLI on Mac/Windows/Linux:

npm i -g reactql

Then run reactql for help, or reactql new to start a new project.

---

This is an early first version, so if you run into any issues, please let me know and I’ll get them looked at ASAP.

I’ve tested the kit on OS 10.12.4 and Windows 10, and it seems to working okay so far. I haven’t tested on Linux yet. Any testing you could do yourselves would be greatly appreciated- and I’d be really interested in your feedback.

These are the main features:

• CLI completely replaces manual git cloning. Just install and type reactql new whenever you want to start a new project.
• Command line options can be used instead of the wizard - type reactql to see a full list of commands and options.
• Easy future versioning. Just npm i -g reactql to get the latest kit at any time (whenever you use the CLI, it’ll check NPM for the latest version and alert you if a new one is available.)
• Clear separation of ‘starter’ and ‘cli’ code-- everything for the starter kit simply goes in the starter folder in this repo. Everything to do with the cli goes in cli. Simple.
• No manual tidy-up – a new starter kit has no .git/README/LICENSE to rip out. You can git init in your new folder neatly.
• Auto population of package.json, based on your project name and description.
• Auto installation of dependencies. It’ll prefer yarn, but drop back to npm if it’s not available.
• Early groundwork for templating. Adding a .reactql extension to a file inside starter/files will run it through an EJS parser with the command line args before dumping a compiled version in the new starter kit, minus the .reactql extension. This is early work against starter kit options that will be presented in the wizard, for enabling SASS, LESS, ESlint, other loaders, etc.
• Usage instructions shown on the screen after installation - npm start runs it.
• Emojis FTW! (only enabled on Mac)

---

This is still early work, so I expect there might be some issues, and code may be a little messy in places (I wrote this over the weekend.) But I think it should be a pretty good start.

Known issues:

• As mentioned, no dynamic options (yet). You get exactly the same kit as v1 for now.

• Windows installation via NPM is pretty terrible. I clocked 116s to build on a relatively new/fast Windows machine, on a 200mbps connection. Yarn on a Mac, by contrast, did it in 39s flat. Bear in mind this is a full installation without a ‘warm’ cache.

• I don’t include a yarn.lock file in the starter by default, because of the potential of making dynamic additions to package.json depending on user options (coming soon). It’s probably best still to have a base lock file, however, to give Yarn a starting point-- I’ll likely do that in the next version.