|
Is there a suitable ELI5 explanation for how to do that? For example, here's one for my current setup:
JavaScript code:
Dominoes fucked around with this message at 08:20 on Apr 4, 2017 |
# ? Apr 4, 2017 08:07 |
|
|
# ? May 16, 2024 17:47 |
|
My go-to advice is create-react-app and then you just:code:
However, you're using typescript. I don't really do typescript much (I don't really do create-react-app either, I have my own custom webpack configuration). It's not exactly ELI5, but the closest is probably to take this example repo, use their webpack.config.js and tsconfig.js. Strip their package.json down to the bare minimum packages (because screw gulp). My actual, non-ELI5, advice is to start here and learn webpack because it's pretty frickin' great and if you're just copying/pasting configs you're going to miss out on a lot of its greatness. I just want to highlight again the biggest reason this is all so stupid complicated is that we're developing for a goddamn stupid environment...the browser.
|
# ? Apr 4, 2017 15:27 |
|
Thanks; going to dig into that. Looks like TSC is a no-go for imports. IDK why this is so hard! BTW, React really is sick! Can't see myself not using it for interactive web pages in the future. NOT a feasible drop-in to an existing site though. Manipulating elements and storing data in IDs, classes, and nesting structure feels hacky in comparison. Dominoes fucked around with this message at 20:59 on Apr 4, 2017 |
# ? Apr 4, 2017 20:57 |
|
Dominoes posted:Thanks; going to dig into that. Looks like TSC is a no-go for imports. IDK why this is so hard! Storing data in HTML elements has always been hacky.
|
# ? Apr 4, 2017 21:01 |
|
Dominoes posted:Thanks; going to dig into that. Looks like TSC is a no-go for imports. IDK why this is so hard! Because there is terrible documentation. It doesn't need to be as simple as this: http://bloodymary.io/ But jesus christ, there seems to be no "definitive" guide to starting a project to "install react" (or anything else) then with grunt/gulp or whatever here is what you have to setup and build. All the articles are about how lovely the documentation is. It really seems to be a black box. That example repo linked above helps, but still translating that to my project doesn't work easily.
|
# ? Apr 4, 2017 22:14 |
|
Dominoes posted:Thanks; going to dig into that. Looks like TSC is a no-go for imports. IDK why this is so hard! It's possible. We have a few react elements on our dashboard. It's only really useful for complex components, but with something like redux (even a small custom version) it's not too bad to work out.
|
# ? Apr 4, 2017 22:25 |
|
I set up a barebones package on github to try to get this figured out, rather than work with my existing project. I'm trying to incorporate info from Therm's latest reply in it. Ideally once this is sorted, I'll clean this up, and leave it up as a Typescript-with-imports quickstart. As posted, running 'tsc' in the main directory successfully compiles typescript or typescript-with-JSX files you add to the 'files' array of tsconfig.json, but breaks when you import anything.
Dominoes fucked around with this message at 22:36 on Apr 4, 2017 |
# ? Apr 4, 2017 22:28 |
|
https://www.typescriptlang.org/docs/handbook/react-&-webpack.html this is a reasonable guide to getting a typescript+react setup.
|
# ? Apr 5, 2017 02:52 |
|
Gul Banana posted:https://www.typescriptlang.org/docs/handbook/react-&-webpack.html poo poo hot! It works! Key to success: Use the config files and directory structure in that link; they set up a chain so that TSC processes the typescript into JS, then webpack makes the module system work. (It appears webpack handles the JSX as well) If your website has more than one page, the module.exports part of webpack.config.js should look like this: JavaScript code:
JavaScript code:
Dominoes fucked around with this message at 12:11 on Apr 5, 2017 |
# ? Apr 5, 2017 11:34 |
|
Dominoes posted:
People hate on JS (and sure its got a lot of bad stuff to it), but the tools are available to make it fairly pleasant to code in.
|
# ? Apr 5, 2017 15:13 |
|
Thermopyle posted:People hate on JS (and sure its got a lot of bad stuff to it), but the tools are available to make it fairly pleasant to code in. However, the tools are unpleasant to work with. :p
|
# ? Apr 5, 2017 23:35 |
|
Maluco Marinero posted:However, the tools are unpleasant to work with. :p yes Well, unpleasant to set up, but after they're set up I don't really ever think about them again.
|
# ? Apr 5, 2017 23:45 |
Thermopyle posted:People hate on JS (and sure its got a lot of bad stuff to it), but the tools are available to make it fairly pleasant to code in. Next to clojure, after including lodash js is by far my favourite to do basically any kind of data transformation in. There's a very cool functional language hiding in all the weird poo poo. I mean, this: The good parts are pretty good.
|
|
# ? Apr 6, 2017 10:12 |
|
I was surprised when I read yesterday that arrow functions can do more than make quick anonymous functions... Here's a boilerplate repo solving the config mess I posted about : Link Suggestions?
|
# ? Apr 6, 2017 11:06 |
|
Dominoes posted:I was surprised when I read yesterday that arrow functions can do more than make quick anonymous functions... dist and node_modules should be gitignored. Use yarn and commit the lockfile (although maybe not if you are using it as a boilerplate template)
|
# ? Apr 6, 2017 18:34 |
|
Deployment setups that use the repo (like Heroku) won't wory with dist ignored. Not sure what a lockfile is; looked a bit up and not sure how it relates.
|
# ? Apr 9, 2017 10:38 |
|
Dominoes posted:Deployment setups that use the repo (like Heroku) won't wory with dist ignored. Not sure what a lockfile is; looked a bit up and not sure how it relates. If you are using Yarn you need it.
|
# ? Apr 9, 2017 17:29 |
|
Looks neat from the description on this page. Is there a good reason not to switch from NPM? My repo size has grown exponentially since switching to npm from <script> tags.
|
# ? Apr 9, 2017 19:21 |
|
Dominoes posted:Looks neat from the description on this page. Is there a good reason not to switch from NPM? My repo size has grown exponentially since switching to npm from <script> tags. Thats one of the reasons you shouldnt be commiting node_modules. You'll have huge commits for no gain. Also, there's not really any downside from using yarn. I just talked about it on the previous page.
|
# ? Apr 9, 2017 19:29 |
|
Switched; painless. How can I avoid committing node_modules with heroku? I'm looking through this page. edit: Woah it looks like it just works! I guess Heroku is reading the package.json and npm installing it like it does with requirements.txt? edit2: When I run "heroku run npm", it doesn't recognize it; it does recognize "heroku run pip". What's going on? After git ignoring and un-caching my node_module directory, it still works on Heroku. Dominoes fucked around with this message at 20:31 on Apr 9, 2017 |
# ? Apr 9, 2017 20:01 |
|
I believe you'll need to configure multiple buildpacks, one for Javascript, and one for Python. Take a look here for an example https://devcenter.heroku.com/articles/using-multiple-buildpacks-for-an-app
|
# ? Apr 9, 2017 20:49 |
|
If heroku sees a yarn.lock file it will automatically run yarn install. Otherwise if it just sees package.json it installs them via npm.
|
# ? Apr 9, 2017 21:16 |
|
Further playing with js / web / node technologies, and I'm trying to author a command-line program installable via npm. With the following package.json,JavaScript code:
I've been poking at some package.json files from different cli packages, but I can't find what I'm missing here. Any suggestions? You can look at the whole shebang at github.com/nilock/lynda-copy-course.
|
# ? Apr 10, 2017 00:29 |
|
Newf posted:Further playing with js / web / node technologies, and I'm trying to author a command-line program installable via npm. With the following package.json, "Please make sure that your file(s) referenced in bin starts with #!/usr/bin/env node, otherwise the scripts are started without the node executable!" From the npm docs
|
# ? Apr 10, 2017 00:51 |
|
Or set your start script as "node dist/lynda-copy-course" Using the "." in front of the slash tells your shell to execute it based on the shebang first, then whatever default handler it has.
|
# ? Apr 10, 2017 04:52 |
|
camoseven posted:"Please make sure that your file(s) referenced in bin starts with #!/usr/bin/env node, otherwise the scripts are started without the node executable!" Yeah, I had read that line in the docs, and almost referenced it in my prior post. Uh, what does that mean? The examples given directly above in the docs are JavaScript code:
JavaScript code:
... Just noticed the "engine": { "node": ">=0.10" } entry here. Is that the difference?
|
# ? Apr 10, 2017 05:36 |
|
It means your script located at bin/ncp needs to have that shebang line
|
# ? Apr 10, 2017 06:00 |
|
Christ, OK, NOW I get it. I thought it meant that the value of the "bin" key had to start with that, which was contradicted by their own examples, and all the examples I could find.
|
# ? Apr 10, 2017 06:03 |
|
This weekend I felt the need to manually setup webpack and react for a personal project, and had decent success with this guide: https://scotch.io/tutorials/setup-a-react-environment-using-webpack-and-babel If you're on Windows, you can't use brew to install yarn, but everything else works unmodified. I also did not install webpack-dev-server since I'm working with Electron and didn't see the need.
|
# ? Apr 10, 2017 17:47 |
|
Does anyone know why you (evidently) need to import react with script tags in addition to import statements? This typescript page describes doing it that way, and indeed, this appears correct. IME The browser can't find React without the script tags; IDEs don't recognize it without the import.
|
# ? Apr 10, 2017 22:26 |
|
Isn't the crappy situation of browsers not supporting ECMAScript import but everything else does?
|
# ? Apr 10, 2017 22:33 |
|
I've never had to do that. I'll look at in in more detail when I get home.
|
# ? Apr 10, 2017 23:14 |
|
MrMoo posted:Isn't the crappy situation of browsers not supporting ECMAScript import but everything else does? TypeScript & Webpack are supposed to solve that in how it creates it's bundle. I think the example listed above just doesn't actually do the bundling of external libraries. Check the bundle.js, if it only contains your code, that's why.
|
# ? Apr 10, 2017 23:21 |
|
Dominoes posted:Does anyone know why you (evidently) need to import react with script tags in addition to import statements? This typescript page describes doing it that way, and indeed, this appears correct. IME The browser can't find React without the script tags; IDEs don't recognize it without the import. I've no experience with typescript. But I'd just add the babel module to translate react to webpack.config.js and that should allow you to not have react in the <script> tags. However, the comments: quote:// When importing a module whose path matches one of the following, just Imply that it was an intentional decision to not bundle react with the rest of the app so that the react library would be cached by the browser.
|
# ? Apr 10, 2017 23:31 |
|
The Fool posted:...an intentional decision to not bundle react with the rest of the app so that the react library would be cached by the browser. This has been nagging at me the whole time that I've been wrangling with webpack. Why exactly do we want to bundle all of these ubiquitous libraries? HelloWorld react apps have a >1mb bundle.js, but surely you could expect lots and lots of users to have cached react served from some cdn.
|
# ? Apr 11, 2017 00:51 |
|
Newf posted:This has been nagging at me the whole time that I've been wrangling with webpack. Why exactly do we want to bundle all of these ubiquitous libraries? HelloWorld react apps have a >1mb bundle.js, but surely you could expect lots and lots of users to have cached react served from some cdn. Yeah I agree with you. My preference is to configure webpack to access a window variable with those requires. For example 'react' just returns 'window.React'. This has been a feature of webpack 1 & 2 by way of externals: https://webpack.js.org/configuration/externals/ This ensures you're running off the most efficiently built version of a library too, as a poorly configured webpack will produce a React that is orders of magnitude slower than the production distribution due to leaving behind developer quality of life error handling, bloating the number of conditionals that need to be handled throughout the codebase.
|
# ? Apr 11, 2017 01:03 |
|
Newf posted:This has been nagging at me the whole time that I've been wrangling with webpack. Why exactly do we want to bundle all of these ubiquitous libraries? HelloWorld react apps have a >1mb bundle.js, but surely you could expect lots and lots of users to have cached react served from some cdn. Well, don't pre-emptively optimize. For a huge number of smaller apps and dev environments, it's just easier to do it with everything bundled together. That being said, Webpack 2 has a built in method to split bundles up, but the documentation recommends actually using this plugin. Which in turn recommends just using <script> tags for the really common stuff. I guess what I'm saying is: Do whatever works for you, and if you find yourself running into performance issues, fix it then.
|
# ? Apr 11, 2017 01:07 |
|
Newf posted:This has been nagging at me the whole time that I've been wrangling with webpack. Why exactly do we want to bundle all of these ubiquitous libraries? HelloWorld react apps have a >1mb bundle.js, but surely you could expect lots and lots of users to have cached react served from some cdn. It's important to note that bundle size is not what you would deploy. The development build of react alone includes a bunch of extra stuff, not to mention minification. But yeah, having a dependency bundle separate from the actual app is good. Or even unbundled dependencies with HTTP/2.
|
# ? Apr 11, 2017 01:57 |
|
From what I've read it's common practice to have Webpack create a separate bundle that has all the third party code in it, and another bundle (or multiple split bundles) of your own code. That way you can make frequent changes to your own code base, and not force the user to re download the third party code.
|
# ? Apr 11, 2017 03:09 |
|
|
# ? May 16, 2024 17:47 |
|
The Fool posted:Well, don't pre-emptively optimize. For a huge number of smaller apps and dev environments, it's just easier to do it with everything bundled together. That being said, Webpack 2 has a built in method to split bundles up, but the documentation recommends actually using this plugin. Which in turn recommends just using <script> tags for the really common stuff. This was extremely helpful, thanks! I have a React "best practices" question. I have an article and I want the user to edit it inline with TinyMCE. Should I re-render the entire object with the react/tiny plugin. I'm guessing just initializing tinymce on the desired element is not the best way to go about this.
|
# ? Apr 11, 2017 04:23 |