Roadmap

[leebenson]

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:

• [x] 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.

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

• [x] 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.

• [x] Typescript option.

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

• [x] 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.

• [x] ~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]

https://github.com/reactql/kit/releases/tag/2.0.0

[leebenson]

CLI v4.0.0 released with kit v2.0.0. npm i -g reactql to upgrade.

[leebenson]

ReactQL CLI v4.4.0 has been released, which adds reactql upgrade powers to new projects.

All files in the newer kit will overwrite old files (except userland src/*, readme/changelog/license files, and any additional/newer files that you may have added that are not present in the kit), your package.json will be merged with the newer variant, and newer NPM packages will be auto-installed.

See https://github.com/reactql/cli/releases/tag/4.4.0 for the full release notes.

As this is a new feature, common sense applies -- back up your existing projects, and don't rely on it to not screw up your project (especially if you've made changes to any kit files... they will be overwritten.)

This release cements the latest improvements to the kit that make it simpler to keep the majority of code in userland (src/) without touching the kit for common configuration options such as adding routes, setting GraphQL schema, pointing to an external GraphQL endpoint, adding a 404 handler, etc.

Sidenote: As of the latest kit v2.4.0, the per-request Redux store and Apollo client is added to Koa's ctx object and available to any later route or middleware you define with config.addMiddleware() or config.addPostRoute(), etc - so you can do interesting things such build REST endpoints that fire Redux actions, and then capture state changes in middleware

It's the precursor to the full-stack auth example that is coming imminently (the next day or two.)

Hopefully this makes upgrades between kits a little less painful.

[karev]

it could also be awsome if we could choose between react and preact from the cli

[leebenson]

@karev - I'm a fan of preact, but I'm not sure it's something we can support in ReactQL by default. This should probably remain a userland exercise.

There's too much of an ecosystem around react - React Router, Apollo, SSR streaming via React 16, etc - that there may be significant chunks that would be subject to change/maintain, even if preact-compat was included.

AFAIK, the main selling point of Preact is a smaller surface area for browser bundling, but in 95%+ of cases this is negligible (the Brotli browser-side vendor bundle weighs in at 90.4kb for everything - most sites will have JPEGs that are bigger). Are there other compelling reasons I'm missing?

[karev]

the only reason that make me consider preact over react is the change of the license made by facebook, https://medium.com/@raulk/if-youre-a-startup-you-should-not-use-react-reflecting-on-the-bsd-patents-license-b049d4a67dd2

[leebenson]

I'm not a patent expert, so qualify this statement with professional advice, but I'd imagine the number of companies using React in production would largely mitigate any risk. That includes some very well known billion-dollar companies outside of Facebook.

Again, not an expert, but I imagine this is largely a non-issue.

[mnpenner]

@karev https://medium.com/@dwalsh.sdlr/react-facebook-and-the-revokable-patent-license-why-its-a-paper-25c40c50b562

The whole article is good, but this tidbit at the end stands out with regard to what you're saying:

I’ve gotten a lot of “well then let’s just all use [alternative framework here].” Hold on a second. If Facebook has patents covering react (diffing, componentization, etc), those patents likely cover Preact/Vue/et al.

But React gives you a patent grant! With an alternative framework, you’re an infringer from day one. This all comes down to whether Facebook has patents and their desire to enforce them, but if you want to war game this to the nth degree, a React alternatives are more risky.

[monefin]

react patent scare campaign is an utter bullcrap from Apache f worried and scared about react community getting too big and the omnipresence of react ecosystem .@Apple uses React. @amazon uses React. @facebook, obviously, uses React. @Microsoft uses React too. What then? https://twitter.com/TomGoldenberg/status/900397048675139585 If FB holds a patent on Virtual DOM then vue.js will also violate that patent because they also use a virtual DOM. If you’re a startup you should use React. You’ll save a tonne of time writing a cross platform Web, Android and iOS app If you ever get to the day that Facebook wants to take you to court (which you will most likely never), it’ll be because you’re already a gigantic success and $$$ is no object to you .

wanna play safe just go use vanilla js ..no one is going to f sue you

[leebenson]

With Apollo 2.0 beta, there's an opportunity for ReactQL to adopt 'real-time by default' and do some interesting things not readily available.

Redux could be replaced by end-to-end GraphQL (think: no reducers, just mutations), Websockets could replace vanilla HTTP for server-pushed data. We could even implement a distributed session cache, that survives server/browser refreshes to reload app state.

Would love to hear your thoughts here -> https://github.com/reactql/kit/issues/80

[scf4]

@leebenson Real time by default sounds amazing, I haven't heard about this. Got a link?

[leebenson]

@scf4 - Real-time by default = GraphQL subscriptions (via websockets)

The difficulty is making a distinction between queries that need to update for everyone listening, and queries that are specific to the local user. I'm toying with implementing a universal cache that can be combined with the subscription logic, to make it possible to do both.

Apollo v2 introduces custom caches/networking that could make the above a little easier.

[scf4]

@leebenson I'm currently handling that with redis (https://github.com/davidyaha/graphql-redis-subscriptions) and it's running pretty well. Are you widening the scope of ReactQL to include the backend too? If so I might be able to help (when I find some free time!)

[leebenson]

thanks @scf4. ReactQL 2.x already includes the server, but I'm toying with expanding to include patterns for subscriptions, caching and push-data.

[leebenson]

https://twitter.com/leeb/status/911385713333039104

[LazerJesus]

maybe include some example of how the write to db process works in this architecture. an input -> calls a mutation -> app updates with new message

[leebenson]

@FinnFrotscher - see the auth example project for a live example of connecting to a DB back-end.

[SimonErich]

Any plans on upgrading to Apollo Client 2? :) Or how soon after release would you include it?

[leebenson]

Any plans on upgrading to Apollo Client 2

Yeah, I'm exploring that now, along with a generally more modular approach to other features of the kit. First step is to convert the kit to Typescript.

No ETA for release, but I'm actively working on it now.

[NotJustClarkKent]

Hey @leebenson, for clarification your direction for this project is to rewrite it in TypeScript and only support TS going forward? I ask because our company decided against TS staying on the ES path (which I suspect will be the case for others) meaning I will need to stop my R&D + recommendation to find another kit. :sob:

[leebenson]

@NotJustClarkKent - whilst the kit itself will be written in TS, you can use plain ES6 in your userland code. It will compile both.

This is the pattern many popular projects are now taking - Apollo, Angular, etc. If you import them from a .ts file, you inherit type info automatically. If not, it's just like plain Javascript.

That's the plan, anyway. I'm still exploring patterns for v3.0. One idea I'm toying with is separating out the Webpack 'launcher' from the Apollo/React kit itself, so the two become separate projects. At the moment, when you use the kit, you inherit a bunch of features you may not want - opinionated CSS, image processing, Helmet for headers, etc. This seems like an obvious place to put that extra stuff in some kind of preset, that can be dynamically loaded into the launcher.

Again, still playing around, so nothing is settled yet. But it's likely it'll wind up something like the above. The end effect would be much cleaner code (with a separate launcher, you wouldn't have to drag around the whole kit each time -- just load the pieces you need), as well as TS.

FWIW, as someone who was previously resistant to Typescript, I'd now highly recommend it. Getting type info during development has already caught a handful of hand-to-trace bugs in our production server code and makes development so much nicer. The thought of going back to the wild west of plain ES6 just seems crazy now.

[SimonErich]

@leebenson I have used and love typescript with angular, quite a bit, so I'm really liking the idea of adding typechecking in there. I'm currently using flow for that though, because it felt like the more react way to me, since it is widely used for and with react. But in the end I wouldn't care as long as we have something like that in there. ;)

[leebenson]

I like Flow too, but TS is emerging as the standard. Would recommend watching https://channel9.msdn.com/Events/Build/2017/B8088/ for the latest features.

[NotJustClarkKent]

@leebenson @SimonErich we're using Flow here as well. [soap box] I've been at this for 18yrs now and I've seen many technologies come and go related to front end (javascript specifically) and my bet on JS over abstractions like Spider, LiveScript and CoffeeScript has kept me sane and less fatigued than my peers enabling me to be more productive. For what it's worth, we choose Flow based on it's balance of type safety, the fact that we still write native JS and that it can be "eject" from our projects when the next type safe flavour of the month language comes along.[/soap box]

That said, this is your project and I respect the direction you set. Further, I want to underscore my appreciation for you putting so much effort into an open source project and sharing your knowledge with the rest of us. A sincere thank you Lee!

[mnpenner]

@NotJustClarkKent TypeScript is backed by Microsoft and a lot of other big players have started to adopt it too, so I don't expect it to go away anytime soon. I'd argue its just as ejectable as Flow. Both add type annotations to your code, so either way you're going to have to strip those away. The only difference is that TypeScript adds a few extra niceties on-top of EcmaScript such as enums but they compile away pretty cleanly so I don't expect it'd be an issue. In fact, I've "compiled" a few TypeScript files by hand by just deleting all the annotations and it runs fine.

That said, I've found both languages to be equally fatiguing. Flow complains so hard out of the box that it's crashed my computer when trying to run the typechecker on an existing project. TypeScript is slightly more forgiving I've found, but if you enable strict everything you'll get a ton of warnings until you figure out how to markup your code just-so (which gets into some crazy type theory pretty fast).

In any case, it seems like TypeScript is winning the race (see Flow vs TS) and for me as the consumer I'd rather only have to install type definitions from one source rather than having to figure out which library is using what for the best IDE support.

[NotJustClarkKent]

Thanks @mnpenner I appreciate the discussion and agree with Microsoft's backing of TS it will be around for the foreseeable future, its more the commitment (if I can call it that) to thinks like the .ts ext and what our team perceive to be more intrusive syntax. But again, thanks for the good counter points and interesting material I'll review. I don't want to hijack this thread so I'll leave it there, but again, thanks for the great discussion! Cheers!

[scf4]

I like Flow and I really wish it was doing better than TS, but it's such a pain to set up, not enough libraries have types, and I often get so many errors from npm modules, mismatched Flow version, or something else.

There's also no way to include all files from your project, so every single file needs to have // @flow at the top.

I figured I should give TypeScript a try after seeing this thread and it's just so much more straight forward. I've also recently switched to VS code (mainly for its autocomplete) and it also seems so well put together — at least compared to Atom/Nuclide which feels like a bunch of packages hacked together.

I avoided TS and VSCode because of my dislike of Microsoft's past (particularly when it comes to web development) but I can't deny this stuff is really good.

Anyway, thank you Lee for all your work on ReactQL!

[leebenson]

The decision to move ahead with TS comes from recent experience.

Historically, we had a community-led TS version of ReactQL, which I never got involved with. At the time, the surface area of ReactQL was tiny, and I didn't really see the point. After 20+ years with both static and dynamically typed languages, my sentiment was that TS was an unnecessary bolt-on that often got in the way of Javascript's expressiveness -- a half-baked type system that would choke when encountering the majority of NPM packages, and could easily be side-stepped by applying any liberally.

Recent experience has proven the above to be somewhat out-dated view. The latest versions of TS are really quite impressive, and I'm quite amazed at how well it infers complex types -- even recursive, generic types -- that I'd expect from a far more mature type system. There have only been two scenarios where I've found it too easy to unwittingly bypass or trip it up -- when using rest parameters inside an Object.assign and when omitting await on a Promise that hasn't explicitly been set a void return type... both of which have open issues/PRs and are being worked on. Apart from that, whenever TS has complained, it's usually had a good reason to do so.

I think a lot of the resistance to TS comes from a combination of:

1. Many JS developers have never encountered a static type system before, and they just don't see the point in it. Why write extra code to get something to compile, when you could just do what you're used to doing and know it should work?

2. Out-dated experience with Typescript, when you had to do all kinds of gymnastics to download the right .d.ts files and then discover things didn't quite match up when you needed to actually use the types. (npm i -D @types/* now solves this for the majority of popular libs... and it's easy to type-as-you-go for everything else.)

3. Disdain for all things Microsoft.

Admittedly, I've fallen into all three camps at some point (although I had plenty of experience with statically typed languages -- most of my back-end systems are written in Go -- it was always nice to fall back to a dynamic language like JS or Python and get the illusion I was being more productive) -- but I now consider TS a boon.

Especially with the surface area of ReactQL increasing... no more "was that method setGraphQLEndpoint or setGraphqlEndpoint or even addGraphQLEndpoint"? Just start typing, and VS Code will tell you / bark at you if you get it wrong.

I also think Microsoft is experience something of a renaissance with their OSS strategy.

FWIW, I think C# is probably the best general-purpose OOP language in the world today... and expect a resurgence in it use in the years ahead due to the fact it can now be bundled in a Docker image. .NET Core 2 adds pretty much the whole .NET framework to Linux/Mac. This can only help Typescript adoption; they're very similar. Plenty of projects are also now adopting it as the de facto language for NPM packages. Look at Angular, Ionic, Apollo 2. I'm often surprised after importing a package that types are there, without adding an accompany @types package.

And, VS Code is a really nice experience with Typescript. Real-time checking is extremely fast- much faster than Atom. I can't actually believe how sluggish Atom is compared, until I open it up and try to do anything. Seriously, if you haven't tried VS Code, give it a go.

I realise many of the above arguments could also apply to Flow. It has the backing of a 12-figure company (Facebook), just like TS (Microsoft). It's part and parcel of core libs we already use (React). It's relatively smart and quite fast (although, perhaps out-dated now, there are reports that it can be sluggish at scale.)

Ultimately, though, I feel TS' latest iterations and its growing NPM dominance give TS the upper hand.

[LazerJesus]

https://github.com/reactql/cli/issues/10#issuecomment-343414491 graphql2.0 any update on this front?

[leebenson]

@FinnFrotscher - it'll be introduced in the kit 3.0 release. ~2 more weeks.

[loganpowell]

Just looping myself in to follow along with the progress. Especially interested in replacing Redux with Apollo Client (state) 2.0!

[LazerJesus]

@loganpowell what about apollo-link-state?

[loganpowell]

@FinnFrotscher yep! I'm using apollo-link-state. Can I just replace Redux in ReactQL seamlessly?

[LazerJesus]

@loganpowell this article explains it well.

[Paddy-Hamilton]

@leebenson great project, good work. just wondering if there was an update on the kit 3.0 release date?

Cheers :)

[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.

[klarstrup]

Thank you Lee, very cool!

On Fri, Aug 3, 2018, 13:17 Lee Benson notifications@github.com wrote:

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.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/leebenson/reactql/issues/10#issuecomment-410223367, or mute the thread https://github.com/notifications/unsubscribe-auth/ABfrkX3bO8HR9voqqBJ67duhApCEFEZYks5uNDE2gaJpZM4M23P- .

[klarstrup]

Oh right - what's up with picking styled-components over Emotion?

[leebenson]

Honestly, for the same reason as any X vs Y stack choice: I played with it for a while, and it worked out well.

I don't know Emotion well enough to comment, but my initial impression is they look very, very similar.

[thm-design]

Awesome! Will be checking this out, thanks @leebenson