What's New in Create React App(facebook.github.io)
facebook.github.io
What's New in Create React App
https://facebook.github.io/react/blog/2017/05/18/whats-new-in-create-react-app.html
119 comments
At the same time, create-react-app just hides that very awful build system.
At some point you will need to make changes — be it to switch to typescript, to add some other cross-compilation tools or modify the build pipeline — an you'll have to fight with the build system.
If create-react-app did not exist, maybe the daily pain of working with the build system would be enough that it would actually be improved.
Because currently, maven is even nicer to work with than the various js build systems.
At some point you will need to make changes — be it to switch to typescript, to add some other cross-compilation tools or modify the build pipeline — an you'll have to fight with the build system.
If create-react-app did not exist, maybe the daily pain of working with the build system would be enough that it would actually be improved.
Because currently, maven is even nicer to work with than the various js build systems.
FWIW, my side project[1] takes the opposite approach: start with a bare minimum project structure, and add pieces on top via a cli. So, for example, instead of starting with Flow by default and having to rip it out for TypeScript, you start with neither, and can run `pult add typescript` if you need to.
[1] https://github.com/Concatapult/pult
[1] https://github.com/Concatapult/pult
By that logic, you could say that leiningen and gradle hide the very awful maven build system, and maybe if they didn't exist, the daily pain of working with maven would be enough that it would actually be improved.
But it's been well over a decade. Maven is maven, npm is npm, make is make. Yarn is doing a good job now of being the new and improved build system for JS projects, and create-react-app seems to be using it under the hood.
Eventually I may care about what compilation flags lein passes to maven in order for it to compile my clojure project into jvm bytecode, but that day hasn't happened yet and I've been glad not to have to set those up with every clojure project I start. The same now applies to react apps.
But it's been well over a decade. Maven is maven, npm is npm, make is make. Yarn is doing a good job now of being the new and improved build system for JS projects, and create-react-app seems to be using it under the hood.
Eventually I may care about what compilation flags lein passes to maven in order for it to compile my clojure project into jvm bytecode, but that day hasn't happened yet and I've been glad not to have to set those up with every clojure project I start. The same now applies to react apps.
But gradle doesn’t build on top of maven. Gradle replaces maven.
That’s the issue I have with npm, webpack, create-react-app.
They just pile more and more layers of abstraction on top, instead of improving or replacing what is below.
That’s the issue I have with npm, webpack, create-react-app.
They just pile more and more layers of abstraction on top, instead of improving or replacing what is below.
I love this and so many command line tools that so many projects are shipping now - actually I have come to expect that projects/frameworks that need multiple files (VueJS, React, etc) have a "component generator" distributed with it, so you can create new components, with the proper up-to-date template, from the command line.
I don't remember when this started - Rails maybe? That was not my thing back then, but I really like this now.
IIRC Elixir has a great tool as well.
I don't remember when this started - Rails maybe? That was not my thing back then, but I really like this now.
IIRC Elixir has a great tool as well.
This sounds really good.
Quick question, does it include an option for client side routing?
I really want to start using React, but every time I get overwhelmed by the sheer amount of options (paralysis analysis) and go back to AngularJS (which is starting to show it's age). Personally I'm not sold on Angular2/4.
Cheers
Quick question, does it include an option for client side routing?
I really want to start using React, but every time I get overwhelmed by the sheer amount of options (paralysis analysis) and go back to AngularJS (which is starting to show it's age). Personally I'm not sold on Angular2/4.
Cheers
They don't load a routing solution with this, but the most used router (and my favorite) is React-Router [0]. To get basic routing setup takes less than an hour, and has great docs.
[0]: https://reacttraining.com/react-router
[0]: https://reacttraining.com/react-router
If you're using redux I would recommend you stay far away from react-router. Using redux-little-router has been a pleasure to use in comparison: https://github.com/FormidableLabs/redux-little-router
(Disclaimer: I work at Formidable)
Can confirm, I absolutely love `redux-little-router`. It feels so natural to dispatch Redux actions to change routes rather than dealing with the song and dance of conditionally rendering <Redirect /> components or trying to figure out when in the lifecycle to call `router.push(url)`.
I especially like pairing it with `redux-saga`- with a little bit of effort, you can end up writing mini-applications for each route which start and stop as the user navigates.
Can confirm, I absolutely love `redux-little-router`. It feels so natural to dispatch Redux actions to change routes rather than dealing with the song and dance of conditionally rendering <Redirect /> components or trying to figure out when in the lifecycle to call `router.push(url)`.
I especially like pairing it with `redux-saga`- with a little bit of effort, you can end up writing mini-applications for each route which start and stop as the user navigates.
Any example repos of this? This sounds fantastic.
Damn, this does look great. A lot of what it does can be solved by using `withRouter` from react-router, but I really like how they use `<Fragment />`
Do I need to eject my create-react-app to use Redux and Redux-Little-Router?
for v4 I feel like the docs aren't all the way there. especially example wise
If you want to go with MVC use this:
https://github.com/Rajeev-K/mvc-router
Such a useful and important tool should really be documented in the React tutorial, etc...
I've been watching the PR for the error message overlay[1] off and on for several months, and it has been a stellar example of OSS community working together to make this feature possible. There were PRs spanning multiple projects, contributions from many users, and it ended up in a fantastic feature that seriously helps all users from novice to expert.
This feature really puts React on the next level, in my book. The CRA team is doing a wonderful job making React accessible to new users.
[1]: https://github.com/facebookincubator/create-react-app/pull/1...
This feature really puts React on the next level, in my book. The CRA team is doing a wonderful job making React accessible to new users.
[1]: https://github.com/facebookincubator/create-react-app/pull/1...
They should finally acknowledge the existence of typescript and not push everyone to their flow. Second of all: reduce the size of this starter kit. Other than that I really like the features.
See https://news.ycombinator.com/item?id=14373433 - Microsoft have just released an official starter kit which uses create-react-app. Not tried it myself yet but it looks great and is well documented
That's pretty sweet, especially because they do so without having to eject.
Direct link: https://github.com/Microsoft/TypeScript-React-Starter
Direct link: https://github.com/Microsoft/TypeScript-React-Starter
Yeah sorry, I linked to the post in the hope that this gains a bit of traction as really want people to be aware that getting started with TS and React is a whole lot easier now! I have a fairly popular blog post on the topic of setting up TS and React that I'll update to point to the Microsoft repo to help spread the word.
Here's the package that adds the TS functionality to create-react-app FYI: https://github.com/wmonk/create-react-app-typescript
Here's the package that adds the TS functionality to create-react-app FYI: https://github.com/wmonk/create-react-app-typescript
ahh cool, didnt know, typescript is the main thing that would make me have to emmediatly eject since I use it for all my js projects these days, thanks!
So now we have competing official React starter kits?
Typescript is the best thing to happen in JS land in years. It finally makes large applications possible without a large element of chaos.
It doesn't push Flow, it just mentions it as an option. It's important to note that Flow is purely additive -- you can drop it in a project and get some use out of it. Typescript is not incremental in that way. You probably want to go all-in on it or not at all which is hard to allow for with a starter framework.
TypeScript is now incremental in that way: https://blogs.msdn.microsoft.com/typescript/2017/04/27/annou...
Have you actually used TypeScript? It's just as incremental as Flow, especially in newer versions. I converted a 100k line Coffee + ES6 codebase to TS with no issues.
> It's just as incremental as Flow
No, because TypeScript is a transpiler and Flow is a linter. You don't have to convert your codebase with Flow -- you can just run it on existing JS.
No, because TypeScript is a transpiler and Flow is a linter. You don't have to convert your codebase with Flow -- you can just run it on existing JS.
Flow is definitely not a Linter. It is a language, like TypeScript. It also has a typechecker, like TypeScript. Unlike TS, which bundles in its own compiler, Flow relies on projects like Babel to provide a compiler. In either case, compilation is mostly as simple as first linking modules, then typechecking, then stripping away types.
You can use TS on a JS codebase as well (with the --allowJs option), or you can leave JS files to a separate build step if you don't want type inference for them. I have used both approaches in the past.
You can use TS on a JS codebase as well (with the --allowJs option), or you can leave JS files to a separate build step if you don't want type inference for them. I have used both approaches in the past.
> Flow is definitely not a Linter. It is a language, like TypeScript
This is absolutely untrue. Have you used Flow? It runs as a completely separate process -- you're literally running Flow as a command which typechecks/lints your code. It does not do any transpilation or modify your code in any way. The only caveat is the Flow type annotations which are A. optional and B. removed at compile time without doing any typechecking. Try it some time -- you can run Flow on existing JS code without modifying either your code or your build process in any way. It'll probably even find some bugs without you needing to add additional type information. This is fundamentally different from Typescript which goes hand-in-hand with a fully-featured transpiler.
To be clear, I use TypeScript and like it a lot -- but there seems to be a persistent perception that Flow and TS are two sides of the same coin. They are not and there are certainly some use cases where Flow fits better.
This is absolutely untrue. Have you used Flow? It runs as a completely separate process -- you're literally running Flow as a command which typechecks/lints your code. It does not do any transpilation or modify your code in any way. The only caveat is the Flow type annotations which are A. optional and B. removed at compile time without doing any typechecking. Try it some time -- you can run Flow on existing JS code without modifying either your code or your build process in any way. It'll probably even find some bugs without you needing to add additional type information. This is fundamentally different from Typescript which goes hand-in-hand with a fully-featured transpiler.
To be clear, I use TypeScript and like it a lot -- but there seems to be a persistent perception that Flow and TS are two sides of the same coin. They are not and there are certainly some use cases where Flow fits better.
I have used Flow for a few projects.
I think we're saying the same thing. By "linter" I mean a program that only checks for stylistic and defined/undefined errors. To me, anything beyond that is a typechecker. Whereas TS bundles a typechecker with a transpiler, Flow keeps the 2 separate (you still need both if your program is written using Flow syntax).
You are using "linter" more broadly, which may be fair as well.
Additionally, both TS and Flow can be used on JS files with zero modification.
I think we're saying the same thing. By "linter" I mean a program that only checks for stylistic and defined/undefined errors. To me, anything beyond that is a typechecker. Whereas TS bundles a typechecker with a transpiler, Flow keeps the 2 separate (you still need both if your program is written using Flow syntax).
You are using "linter" more broadly, which may be fair as well.
Additionally, both TS and Flow can be used on JS files with zero modification.
Where are they pushing flow in create-react-app?
https://github.com/facebookincubator/create-react-app/blob/m...
They are supporting flow but not TS.
Maybe writing "push" was a bit of an over statement from my side but for how well typescript plays with react and JSX and how much more popular it is compared to flow it should be either supported by them or flow shouldn't be. Currently they are discriminating in favor of flow. Which I mean they have 100% the right to do, its their product but as an end user I simply want to express my desire in that feature being first class.
They are supporting flow but not TS.
Maybe writing "push" was a bit of an over statement from my side but for how well typescript plays with react and JSX and how much more popular it is compared to flow it should be either supported by them or flow shouldn't be. Currently they are discriminating in favor of flow. Which I mean they have 100% the right to do, its their product but as an end user I simply want to express my desire in that feature being first class.
The reality is not that we don’t want to support TS, but that its pipeline is significantly different from what we use at FB, so we neither have the expertise, nor can integrate the other tools we rely on. This might get better as AST interop between tooling improves.
Yep, and we (Babel) are trying to work with TS on integrating it into Babel similar to how flow works with Babel (parser support + a plugin/preset to strip types). Again, limited resources so if the community really wants it, we would appreciate help in reviewing PRs and testing!
https://github.com/babel/babylon/issues/320, https://github.com/babel/babylon/issues/523
https://github.com/babel/babylon/issues/320, https://github.com/babel/babylon/issues/523
That's awesome, I didn't even know that was a potentially viable route! Thanks for sharing :)
Yeah it's definetely a lot of work on both ends (also means would need to coordinate releases of both like we do with flow) but hopefully this helps the ecosystem that wants to use both (seems to be an increasingly higher number of people).
>They should finally acknowledge the existence of typescript and not push everyone to their flow.
They should support a niche third party competitor tool on their freely available and FOSS tooling?
They should support a niche third party competitor tool on their freely available and FOSS tooling?
>niche
wrong. typescript is vastly more popular than flow.
>competitor tool
hey if they got that thinking, its fine. its their product but from my user perspective I just want to let them know that I could really use some first class TS support.
wrong. typescript is vastly more popular than flow.
>competitor tool
hey if they got that thinking, its fine. its their product but from my user perspective I just want to let them know that I could really use some first class TS support.
>wrong. typescript is vastly more popular than flow.
Irrelevant, as both are still niche.
Irrelevant, as both are still niche.
According to npmjs.com:
- TypeScript: 4,745,783 downloads in the last month
- Flow: 889,612 downloads in the last month
- TypeScript: 4,745,783 downloads in the last month
- Flow: 889,612 downloads in the last month
I'm guessing you're looking at `flow-bin`, which was not the official way to get the Flow binary for a long time (nor was installing it per-project), because the underlying executable isn't JavaScript. It would be more accurate to measure `babel-preset-flow`: https://www.npmjs.com/package/babel-preset-flow (2M in the last month)
Good catch. I also couldn't get numbers for `brew install flow` - are these tracked somewhere?
They are! https://brew.sh/analytics/install/
Awesome. So we have 159,359 downloads via brew over the last year.
I wouldn't use M$ product. There is no guarantee that they either abandon it or start charging an arm and leg for use
It's open source under the Apache Licence. Worst case scenario, the community would fork it and take over, but I don't think doing so would be remotely in Microsoft's interests. I genuinely believe the Microsoft of today is a totally different company in its attitude to open source software than it was even 10 years ago.
They are not. They sold me VS knowing well it will be obsolete in couple of months time and won't refund or discount upgrade. Absolutely vile company.
It's been close to 2 decades since the "M$" moniker had any relevance. This is not 1997 and we are not in the "browser wars".
I would be interested if anybody has tried both CRE and Neutrino.js (https://neutrino.js.org/) and could share their experience with Neutrino? Was it worth it? I'm thinking of using Neutrino.js for my next project (because with CRE you're running against walls if you need just one simple customization from the given defaults, which means to eject)
I had to go to the release note to see what version this applies too. But as usual in JS-land, it's not that easy: This applies to version 1.0.0 of the create-react-app uber-project, whereas if you install/update your create-react-app npm, you'll see version number 1.3.1, as that's a separate sub-package.
Naming that setup after a Greek monster seems apropos.
Naming that setup after a Greek monster seems apropos.
The 1.0.0 version is for the `react-scripts` package that `create-react-app` puts in your project. That's the dependency that anyone who's actually using `create-react-app` in a project is actually interested in (since projects created with `create-react-app` don't actually depend on `create-react-app` – it's just a simple CLI). `react-scripts` is the bulk of the project.
Yea, sorry this gets confusing. There are good reasons for why we do this, but it can be annoying in blog posts.
Here is an explanation:
https://github.com/facebookincubator/create-react-app/blob/m...
Here is an explanation:
https://github.com/facebookincubator/create-react-app/blob/m...
I'm currently evaluating using create-react-app. Could someone please confirm the following for me:
(1) Without ejecting, it's not possible to use 'styled-components'
(2) Would need to eject to do server-side rendering
(3) There's no hot module reloading
Not saying these things are deal breakers at all, create-react-app is really great. Just making sure I've got my pros and cons list correct! Thanks for any help
Not saying these things are deal breakers at all, create-react-app is really great. Just making sure I've got my pros and cons list correct! Thanks for any help
styled-components works fine with unejected create-react-app, I use this combination all of the time. Server-side rendering would probably still need ejecting, though, for access to the Webpack and Babel configuration. Same for hot module replacement, which in create-react-app is only enabled for CSS files as far as I know.
Webpack's HMR (hot reloading) of JS does work with create-react-app, but only if you use an external state store (like Redux), see [1].
The 'React Hot Loader' [2] module, which maintains local React component state is not included yet.
[1] https://github.com/facebookincubator/create-react-app/issues...
[2] https://github.com/gaearon/react-hot-loader
The 'React Hot Loader' [2] module, which maintains local React component state is not included yet.
[1] https://github.com/facebookincubator/create-react-app/issues...
[2] https://github.com/gaearon/react-hot-loader
What does "ejecting" mean?
(I might be wrong on the specifics) create-react-app abstracts a bunch of things for you. Ejecting bakes out those things (dependency versions and configuration files), but can no longer update create-react-app after that or "unbake."
https://github.com/facebookincubator/create-react-app#conver...
Usually, you'd want to do this if you want do implement one of the "limitations" cited or if you had specific things to configure that had been abstracted away.
For example, the release notes mention webpack 2 changed their configuration. If you hadn't ejected yet there's nothing to do because they took care of it on the back end, if you had ejected you have to update your webpack config.
https://github.com/facebookincubator/create-react-app#conver...
Usually, you'd want to do this if you want do implement one of the "limitations" cited or if you had specific things to configure that had been abstracted away.
For example, the release notes mention webpack 2 changed their configuration. If you hadn't ejected yet there's nothing to do because they took care of it on the back end, if you had ejected you have to update your webpack config.
Got it, thanks for the explanation. Not sure what "bake" means either exactly but it seems to read like it fixes versioning or sets up specific configs / changes such that you are not tied to the update / release cycle of the larger app.
"Bake" would mean write out the config files permanently. Not sure how it works on the back end but imagine create-react-app writes out a config on-the-fly each time you launch it. That means it can update the dependencies and makes sure everything places nice together when changing versions. Writing out config files give you more control, but you'd have to update the tools and config manually and might mess up dependencies.
In my experience, setting it all up and getting dependencies is one of the pain points with react, so it's nice to get some sane defaults and get to writing your app. But it is nice to take the time to do everything manually at least once to see what's under the hood.
In my experience, setting it all up and getting dependencies is one of the pain points with react, so it's nice to get some sane defaults and get to writing your app. But it is nice to take the time to do everything manually at least once to see what's under the hood.
It's nice to see built-in offline caching support with service workers. Can anyone explain how this cache gets invalidated when a change is made to the code?
After the app is loaded, the registerServiceWorker.js is executed. It checks for updated sources and updates the cache then. For the user to actually see those changes, the user will need to refresh the page. The relevant lines are here [0].
[0] https://github.com/facebookincubator/create-react-app/blob/m...
[0] https://github.com/facebookincubator/create-react-app/blob/m...
Awesome, thank you!
Why do you need a service worker for caching? I thought the browsers did this by default.
This is offline cache, you can run your application even without internet connection.
What are some examples where offline works for a web app? It seems like the utility is really niched so I don't understand why they make this default. None of the things I've made would make sense using offline (completely anecdotal but still).
I don't know about making it the default, because there are tradeoffs with regard to the cache invalidation.
That said, offline-friendly app caching with Service Workers is extremely useful, and changed the way I see and make web apps.
Now when I use a web app that isn't offline-friendly, I get annoyed. Always demanding a live internet connection obviously creates latency and unreliability for apps.
I changed a former client's app to be offline-friendly with Service Workers, and the benefit was obvious: their app now loaded immediately for repeat users, and they could access much of their data even when they were offline (on a flight, on a crappy Wi-Fi, etc etc).
I made a side-project to help my band members share and edit chord/lyrics sheets (also using Web Audio to give karaoke-style chord playback!) and again I made sure to set up full Service Worker caching. I also used PouchDB for the user data, which was beautiful: I didn't need to run any database server (we just used Cloudant's free instances), all our songs were synced into local browser storage (in real-time when online), and most importantly, the whole app worked perfectly while in the basement rehearsal space that completely blocks mobile signals.
(I'm not working on it nowadays. It's up on https://sketch.band and the code is at https://github.com/mbrock/sketchband under AGPL3. If you wanna try it, the undocumented syntax for the song is: each line should look like "C Dm7 / Once upon a time you dressed so fine".)
Basically offline-first technologies really help make the web into a good platform for apps.
That said, offline-friendly app caching with Service Workers is extremely useful, and changed the way I see and make web apps.
Now when I use a web app that isn't offline-friendly, I get annoyed. Always demanding a live internet connection obviously creates latency and unreliability for apps.
I changed a former client's app to be offline-friendly with Service Workers, and the benefit was obvious: their app now loaded immediately for repeat users, and they could access much of their data even when they were offline (on a flight, on a crappy Wi-Fi, etc etc).
I made a side-project to help my band members share and edit chord/lyrics sheets (also using Web Audio to give karaoke-style chord playback!) and again I made sure to set up full Service Worker caching. I also used PouchDB for the user data, which was beautiful: I didn't need to run any database server (we just used Cloudant's free instances), all our songs were synced into local browser storage (in real-time when online), and most importantly, the whole app worked perfectly while in the basement rehearsal space that completely blocks mobile signals.
(I'm not working on it nowadays. It's up on https://sketch.band and the code is at https://github.com/mbrock/sketchband under AGPL3. If you wanna try it, the undocumented syntax for the song is: each line should look like "C Dm7 / Once upon a time you dressed so fine".)
Basically offline-first technologies really help make the web into a good platform for apps.
An example is a webmail client, where in offline mode you can schedule new emails to be sent as soon as you get online again, and where you can still read the emails you've read before.
Isn't it the case that the offline resources are considered "caches" and thus might be cleaned up if there's not much storage left?
Yes, as far as I know, storage space is still limited, so you wouldn't want to be storing GBs of offline emails. I'm not sure how enforcing works nowadays - it used to be that old offline data would be culled (I think that was for AppCache), but that might work differently with Service Workers.
There are a lot of strategies for supporting offline state in your app: https://jakearchibald.com/2014/offline-cookbook/
In dashboard application, I store data in browser and notify users about last sync time: http://wstaw.org/m/2017/05/19/dashboard.livechatinc.com-iPho...
In dashboard application, I store data in browser and notify users about last sync time: http://wstaw.org/m/2017/05/19/dashboard.livechatinc.com-iPho...
It‘s not just about offline, but about serving assets instantly on repeated visits (while they update in background). You don’t need to wait for request at all.
>What are some examples where offline works for a web app?
Tons of web apps that work in offline mode, which we had since a decade or so -- from games to utility apps.
>It seems like the utility is really niche
Hardly.
Tons of web apps that work in offline mode, which we had since a decade or so -- from games to utility apps.
>It seems like the utility is really niche
Hardly.
It's also nice to be able to selectively cache some data offline so that users aren't greeted with a "you are offline" screen when they hit your web page without a network connection.
For an e-commerce website, this might be the user's shopping cart and favorites. For a note taking app, this might be the last note the user edited. For a Twitter client, this might be the user's drafts and the last 100 tweets on their timeline. This way, the app can say "you're offline, but you can still look at some of this data and do things with it, and we'll sync you up when you get back online".
Native apps already do this. E.g, try posting a picture to Instagram while you're offline.
For an e-commerce website, this might be the user's shopping cart and favorites. For a note taking app, this might be the last note the user edited. For a Twitter client, this might be the user's drafts and the last 100 tweets on their timeline. This way, the app can say "you're offline, but you can still look at some of this data and do things with it, and we'll sync you up when you get back online".
Native apps already do this. E.g, try posting a picture to Instagram while you're offline.
With PWA by default, does it mean react app will be mobile friendly by default and react native is no longer needed to build mobile apps?
Not really. You still have to do a some work to make use of PWA features. This release just integrates the sw-precache-webpack-plugin into the build system so it's easier to add a ServiceWorker to your app should you decide to do so. Here's the documentation: https://github.com/facebookincubator/create-react-app/blob/m...
Also, ServiceWorkers are not just useful on mobile! Applications targeting desktop browsers benefit from them just as much, especially if you're thinking offline-first.
Also, ServiceWorkers are not just useful on mobile! Applications targeting desktop browsers benefit from them just as much, especially if you're thinking offline-first.
React Native is for building native mobile applications, React is for building (mobile) websites. So, no, not exactly, but it does make it simpler to create a nice mobile experience for users if a native app is not required.
Maybe he means (if OP thinks like me): can I have the app on the home screen like real apps? The answer is probably no, you still would be the "Add to desktop" which most users won't use, and the app won't be on the app store..
I have found a bug in it, which was in there in its inception. Should I submit this issue, or simply make a pull request with fix?
A little aside - does anyone know what's the colorscheme / theme of the editor in that blogpost?
I think it's the Atom default dark theme, or similar to it. The font used is Operator. https://www.typography.com/blog/introducing-operator
Operator Mono + Sublime with Spacegray + Oceanic Next
Awesome, thanks for the correction. For the gp, if you haven't seen the base16 stuff there's a lot of similar themes to choose from to get the right one for you.https://chriskempson.github.io/base16/
Oh cool thanks! useful link too
love create-react-app, to get up and running but I've never liked keeping it that way.. I've found ejecting and forging forward from the base react app is best.
Curious: What makes you need to eject?
having access to the webpack config to set things up the way I like and such. I've also had issues with getting SCSS to work before I eject as well pretty continuously through the versions.. not sure why.
What things in create-react-app are not the way you like? Maybe we can make them better for everyone. :)
First class typescript support instead of having to rely on https://github.com/Microsoft/TypeScript-React-Starter
kerojan(1)
Shameless plug but we are hiring React Native developers at Dave.com in Los Angeles if anyone is looking. Email [email protected]
Off topic, but whenever I see an animation of someone writing an import-statement in Javascript by hand I cringe a little.
This stuff costs so much time, use an IDE or some auto-import plugin for eslint.
This stuff costs so much time, use an IDE or some auto-import plugin for eslint.
When I see overeliance on IDEs I cringe a lot.
If the thing that slows down my programming is writing import statements by hand, then I have worse QA issues than that.
If the thing that slows down my programming is writing import statements by hand, then I have worse QA issues than that.
Writing import statements actually slowed down my angular 2 development by a lot. I was trying to break down functions into tiny components and composite them together and ended up with lots of components in separate files.
Modularity is good and all, but explicitly declaring each single dependent component (external libraries and other internal components) when writing new components and adding new ones as you need more dependencies is quite painful and tedious.
Modularity is good and all, but explicitly declaring each single dependent component (external libraries and other internal components) when writing new components and adding new ones as you need more dependencies is quite painful and tedious.
>Modularity is good and all
Up to a point though -- "break[ing] down functions into tiny components" doesn't seem to be on the good side of modularity, but more like the lpad npm fiasco.
Up to a point though -- "break[ing] down functions into tiny components" doesn't seem to be on the good side of modularity, but more like the lpad npm fiasco.
Reducing cognitive load by removing the need to write imports by hand means you have QA-issues? I don't follow.
You didn't wrote about "reducing cognitive load". You wrote: "This stuff costs so much time".
So, my reply to that comes down to:
If you have so many imports that it costs you "so much time" to handle them manually, then you probably have QA issues -- like people adding tons of dependencies to your project.
But it was also meant in the way that if you code so fast, that manually adding some imports is what slows you down ("takes so much time") then probably you are not thinking about what you code enough.
Typically, even without automated imports, the time to handle imports would/should be a negligible amount compared to the time to write the actual functionality -- that's the difficult part, and that what takes one time to think, design and code right.
So, my reply to that comes down to:
If you have so many imports that it costs you "so much time" to handle them manually, then you probably have QA issues -- like people adding tons of dependencies to your project.
But it was also meant in the way that if you code so fast, that manually adding some imports is what slows you down ("takes so much time") then probably you are not thinking about what you code enough.
Typically, even without automated imports, the time to handle imports would/should be a negligible amount compared to the time to write the actual functionality -- that's the difficult part, and that what takes one time to think, design and code right.
While no-one would dispute the need of proper design, there are workflows like refactoring React/HTML-subtrees, where time is wasted having to fix imports whenever you cut something out and put it into a new file.
Or having to manually write "import React from "react"" on top of every single new component.
Or having to write "import _ from lodash" whenever you need to access _ for some function.
Or having to manually write "import React from "react"" on top of every single new component.
Or having to write "import _ from lodash" whenever you need to access _ for some function.
we're talking about 3-4 seconds here.
Which plugin would you recommend? Is there editor integration, i.e. With Sublime?
I use eslint-plugin-auto-import and eslint-plugin-jsx-import (the latter I have hacked together for myself, it's undocumented and brittle)
It get's triggered on each save in TextMate, which I use.
It get's triggered on each save in TextMate, which I use.
Thanks!
[deleted]
What do you do with all that saved time?
The first and obvious benefit is being able to quickly create new projects without having to think about build infrastructure, which is honestly the most painful part of building a modern React project. create-react-app makes all the hard choices for you and gives you a reasonable set of defaults to work with. It's convention over configuration, kind of like Rails. It's a huge game changer.
The less obvious benefit is that it forces developers to fall into the pit of success by making it easy to do the right thing. Flow is supported out of the box, so adding type checking to your app is trivial. Jest is set up for you out of the box, so you have no excuse to not add tests. This new version includes support for code splitting, so there's no reason to ship bloated JS bundles to your users. Building a PWA is easy, so you start thinking about offline-first right at the start of your project.
I can't thank the team behind this little tool enough for making it so easy and so much fun to build React applications!