Roadmap #10
Comments
|
How would you feel about using react-loadable as the higher order component for code-splitting? Using it's babel plugin it works well with with webpack, server side rendering, and ensuring that the react checksum matches on client side hydration. James Kyle has a gist to show how server side rendering would work with it, but I haven't yet seen any examples of it working yet. |
|
Thanks @jtmthf, looks promising. Will play around with it and see if it fits the build flow. |
|
One more thing I'd like to see, but I'm not sure if it fits within the scope of ReactQL, is SVG icon support. I know there's already a loader for Something like svg-sprite-loader or external-sprite-loader would be good. However, the latter won't work on CDNs as far as I'm aware because of a stupid CORs issue the browser vendors refuse to fix, and the former doesn't support SVGs in CSS. Alternatively, the icons could be packed into a webfont, which is still the better solution IMO. However, I haven't seen a loader that does this this yet. Icons are pretty popular in web apps, so I think some sort of icon solution would be good. |
|
@mnpenner, I'm toying with the idea of building a modular 'recipe' build flow for the starter kit, where it'd be possible to add in separate loaders out-the-box by either specifying options on the command line, or working through some kind of CLI wizard. This would make it possible to add in supported loaders like the SVG support you mentioned, but without need to anticipate every use-case and causing bloat for those that don't specifically need it. Already, including SASS and LESS is probably an assumption too far for many dev, but included in every kit by default. I've started a 'cli' branch locally that would turn the basic I imagine it something like Semantic UI's wizard (but without gulp): Still working through it, but something like that is my goal. |
|
@leebenson Hah... I started pretty much the exact same thing like a week or two ago. I'll make it public so you can take a look. It's not very far long along though. You're welcome to pillage anything you think is useful. In particular, I used prettier to clean up the source after I finish generating it, and I was planning on keeping a My goal was to generate a webpack config file that's still human-readable and editable at the end so that you can tweak it as much as you need. I realized that there's far too many questions that you can ask a person, so it's probably better to leave some questions out, just ask the big ones, and they can modify it later. |
|
Just a heads-up that the first version of the CLI has now been released with the 2.0.0 tag.
Quick startInstall the ReactQL CLI on Mac/Windows/Linux: npm i -g reactqlThen run 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:
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:
|
|
Thinking about the templating engine some more (intended to allow the user to enable/disable various loaders, drop CSS support, etc), I'm considering separate repos instead. There could be a common 'base' repo, which is bare-bones -- no CSS, no SASS/LESS, no ESLint, etc. just the bare minimum to get it run. Then a 'kitchen sink' version, which is every best-practice and configuration option, with possibly a couple of other flavours for experimental or community driven approaches. This would allow devs to choose from a slim starter kit, or something more comprehensive for starting a new project. If the code is laid out in a slightly more modular way, it may be possible to inherit from a base repo and then just layer on top. I need to think about that some more, but maintaining needn't be difficult if done properly. And it'd provide a lot more flexibility than template files with conditional statements to include/exclude lines of code. In this model, the CLI would be relegated to the simple role of letting the user choose the theme, and then downloading/extracting the appropriate What do you think? Would you be interested in being able to choose from several 'flavours' of kit with additional features? |
|
@leebenson Yep! That‘s a good way to go IMO. Nice job with the CLI! |
|
@leebenson I like that approach better over templating. I used redux-cli about a year ago which uses ejs templates for code, but it was hard to work with because the templates weren't real javascript. I ended up writing a poorly maintained eslint plugin for ejs specifically for that project, but I'm not sure if it even works anymore. Any ideas yet on how upgrading will work? Having the easy upgradeability of Next.js and create-react-app would be ideal, but being able to customize anything when needed is great too. Related to customization, I was thinking about how Storybook currently handles this by providing both a simple config mode and a "full control" mode. For example if a developer needed to add a single loader, it would be nice if there was a configuration file separate from |
|
I prefer this starter kit specifically because I can customize anything. If you were to remove that ability in favour of upgradeability, I think that might be a deal-breaker. That said, upgradeability certainly is nice, just not in lieu of flexibility. To do this right, I think it needs to be very modular. Lots of small helper scripts/functions that can be subbed out as needed. The source for those can be tucked away so that they can be upgraded without conflicts. As for the repo-splitting: I think it's OK, as long as the CLI tool downloads and manages those automatically. I don't want to be cloning 5 different projects to get all the functionality I need. That defeats the purpose of a starter kit. If I wanted that, I'd download and install webpack, React, GraphQL and whatever else myself. I don't think I mind too much if the CLI tool itself gets fat because of all the functionality it supports. In the end, it spits out a ready-made project, and as long as you didn't pick too many options, that project would still be "light". So, whether or the CLI tool is one repo or many doesn't matter to me as a user, however, for the purposes of maintaining the tool, multiple projects may be easier as long as you can ensure that they don't become incompatible with each-other. Babel comes to mind -- they split that into many packages and it seems to be working for them, so maybe it's doable -- but it is a pain in the butt because every time I add or remove a plugin/preset from my Last thought -- if I have to start using this |
That's the issue I ran into here. Mixing EJS (or any templating) with JS turns it into a weird hybrid that is tough to maintain, and will fail every linter. Makes editing/maintaining the kit less fun than I'd like.
Thinking about it some more, I'm not sure upgrading is that big of a priority. With frameworks like Meteor, where the whole platform is hidden behind a CLI and the only code written is userland, there are clean lines between what is 'kit' and what is 'code'. Here, the starter kit and user code is tightly coupled, and this fusion will make it hard to do auto-upgrades without some very intelligent merge strategy to figure out what has changed. It's mirky territory to start digging into. There are plenty of frameworks (Next.js, et al) that hide the build details from the user and upgrading simply means bumping the Next libs that are imported. My intention with this starter kit was instead of expose the whole lot so it could be configured by the user without any larger ecosystem buy-in. Upgrading kinda breaks with that. Besides, in practice, upgrading generally won't be that hard. Just start a new project, copy over
I've used Storybook on multiple projects, and wrestled with their webpack config more than a time or two to get it to fit with the config of the underlying project I'm trying to test. I ended up writing code that attempted to 'extend' the config, and merge in changes via I get the benefit of offering a framework, but I think sticking to the raison d'etre of ReactQL being a starter kit is probably best. |
Agreed. Per my comment above, I'm not sure upgrading will generally be that tough. In a starter kit like ReactQL, version bumps don't need to happen just because the new kit has a higher number than the one you're using. Knowing when to fork your code and start maintaining it outside of the kit is just as important.
That's the whole point of the CLI - to ask a bunch of questions, handle the download/building and leave you with code you can immediately edit. You'd download the CLI one-time, and it'd handle the rest for you. No need to faff with other repos or even now/care they exist.
That's definitely not my intention. IMO, the CLI should be there one-time - right at the start of the project, to get the initial code. Then, the code is yours, and you're not 'locked' into the ReactQL ecosystem, but instead building with 'native' NPM commands and everything else that the libraries you're using expose directly. This is in contrast to, say, the Meteor CLI, which provides a ton of ongoing functionality and the entire framework that you invoke every time you run your code. That approach works great for full frameworks, but is too big a buy-in for a starter kit, IMO. |
|
I've just released 2.2.0 which relegates the CLI to a pure build tool. The starter kit code is now located at https://github.com/reactql/kit Future issues should be posted above as needed. The CLI issue board will specifically be for the CLI tool only. This is a precursor to allowing multiple 'flavours' of kit to be hosted and maintained separately, each with its own contributors/maintainers and issue boards. I don't necessarily want to encourage lots of different kits, but at a minimum I see two - the 'kitchen sink' version above, and perhaps a 'slim' version that removes the CSS, optional loaders and examples found in the fuller variant. Right now, the CLI automatically downloads, extracts and builds the full version, with no other kits to choose from. Eventually, the 'slim' option will be added too, and this will appear during invocation of I think this is a cleaner separation of concerns than bundling code along with each kit, and having lots of different EJS templates that include/drop lines of code depending on deeply nested The other nice thing is that you can pull the repo code directly if you wish to bypass the CLI altogether. The CLI is now simply a helper. Which also means that fixes to the underlying kit won't require bumping to a new CLI version... a user will get the latest version every time they invoke Tested it on Mac and Windows 10 and appears to be working well. |
|
@leebenson will the list of kits be hard-coded into CLI or will there be an option to pass in a URL to a third-party kit such as how |
|
Hard-coded, at least for now. I don't have any plans to support third-party kits - I think that's mirky territory for ReactQL branding. Third-party kits are free to fork the CLI, though. |
|
Okay reason why I ask is I have a TypeScript fork of the kit that some could find useful. Identical to the original except for the application code and the transpilation step of the build. |
|
@jtmthf - if you're interested in maintaining an official Typescript version, I'd be happy to set-up a kit.ts repo and appoint you as a maintainer. Up for it? |
|
@leebenson That'd be great! What I've been doing so far and plan to continue with, is to track kit and only make TypeScript specific modifications. |
|
Cool, thanks @jtmthf. I've invited you to the repo @ https://github.com/reactql/kit.ts Once that's up and running, I'll update the CLI to let devs choose between the JS or TS version. |
|
Heads-up: Kit v1.3.0 was just released, which adds a development web server that restarts automatically on code changes -- making it easier to test CSS output and SSR on-the-fly, without manually re-bundling on the command line:
The next ReactQL CLI project you create will add this capability for you via the usual There's also a ton of other improvements, including neater Webpack messages, ESLint speed improvements and a fix for Atom, colour console messages that show local network bindings and ports in dev/production, See the release log for details. |
|
CLI v2.4.0 has been released. It adds deterministic versioning of the kit; each CLI release is associated with one JS / Typescript kit pair, making it clear what you're installing and making it easy to install the same version of the kit elsewhere. This way, the next time you run The update notifier will let you know when a new ReactQL kit is available. To upgrade the CLI to 2.4.0, simply re-install with |
|
thanks @scf4. ReactQL 2.x already includes the server, but I'm toying with expanding to include patterns for subscriptions, caching and push-data. |
|
maybe include some example of how the |
|
@FinnFrotscher - see the auth example project for a live example of connecting to a DB back-end. |
|
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. |
|
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. 😭 |
|
@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. |
|
@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 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. |
|
@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! |
|
@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. |
|
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! |
|
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 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! |
|
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 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 I think a lot of the resistance to TS comes from a combination of:
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 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 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. |
|
#10 (comment) graphql2.0 |
|
@FinnFrotscher - it'll be introduced in the kit 3.0 release. ~2 more weeks. |
|
Just looping myself in to follow along with the progress. Especially interested in replacing Redux with Apollo Client (state) 2.0! |
|
@loganpowell what about apollo-link-state? |
|
@FinnFrotscher yep! I'm using apollo-link-state. Can I just replace Redux in ReactQL seamlessly? |
|
@loganpowell this article explains it well. |
|
@leebenson great project, good work. just wondering if there was an update on the kit 3.0 release date? Cheers :) |
|
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 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. |
|
Thank you Lee, very cool!
…On Fri, Aug 3, 2018, 13:17 Lee Benson ***@***.***> 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
<#10 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABfrkX3bO8HR9voqqBJ67duhApCEFEZYks5uNDE2gaJpZM4M23P->
.
|
|
Oh right - what's up with picking styled-components over Emotion? |
|
Honestly, for the same reason as any I don't know Emotion well enough to comment, but my initial impression is they look very, very similar. |
|
Awesome! Will be checking this out, thanks @leebenson |
and others
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 withreactql newinstead 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 SSR + code-splitting #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 (Progressive web app #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)
The text was updated successfully, but these errors were encountered: