Javascript questions which don't deserve their own thread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »

Dominoes: Sep 20, 2007

Is there a suitable ELI5 explanation for how to do that? For example, here's one for my current setup:

Install npm with an installer
run npm install -g typescript
rename files from .js to .tsx exension
Select 'transpile with typescript' in PyCharm settings
Add a tsconfig.json file to the directory with your files; make it look like this:

JavaScript code:

{
    "compilerOptions": {
        "module": "commonjs",
        "removeComments": true,
        "preserveConstEnums": true,
        "sourceMap": true,
        "jsx": "react"
    },

    "files": [
       //go here
    ],

    "typeRoots": [
        // add path to @types
        "node_modules/@types"
    ]
}

To clarify, the only thing that's not working with this setup is importing npm modules vice using script tags in the template.

Dominoes fucked around with this message at 08:20 on Apr 4, 2017

# ? Apr 4, 2017 08:07

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 12:08

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

My go-to advice is create-react-app and then you just:

code:

npm install -g create-react-app

create-react-app my-app
cd my-app/
npm start

Then you just work in PyCharm and your stuff automatically gets compiled and served.

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

Dominoes: Sep 20, 2007

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

The Fool: Oct 16, 2003

Dominoes posted:

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.

Storing data in HTML elements has always been hacky.

# ? Apr 4, 2017 21:01

geeves: Sep 16, 2004

Dominoes posted:

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.

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

necrotic: Aug 2, 2005; I owe my brother big time for this!

Dominoes posted:

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.

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

Dominoes: Sep 20, 2007

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

Gul Banana: Nov 28, 2003

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

Dominoes: Sep 20, 2007

Gul Banana posted:

https://www.typescriptlang.org/docs/handbook/react-&-webpack.html
this is a reasonable guide to getting a typescript+react setup.

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:

module.exports = {
    entry: {
        my_module1: "./src/my_file1.ts",
        my_module2: "./src/my_file2.ts",
	// ...
    },
    output: {
        filename: "[name].js",
        path: __dirname + "/dist"
    },

Import syntax looks like this:

JavaScript code:

//modules from npm
import * as _ from 'lodash'

// project files -- must prepend 'export' to all variables and functions you want available.
import * as util from './schedule_utilities'
import * as validation from './schedule_validation'
import * as autofill from './schedule_autofill'

Overall: this setup process is a mess, but I'm impressed with the way you can code in JS once it's setup. I'd messed with JS before, and went in with the mindset "This is going to be ugly, and I'm going to have to code everything from scratch" ES6's new syntax features, (most notably for of loops, arrow funcs, and map/filter), static type checking, and a python-like import system make this pretty cool! Lodash fills in the gaps.

Dominoes fucked around with this message at 12:11 on Apr 5, 2017

# ? Apr 5, 2017 11:34

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Dominoes posted:

Overall: this setup process is a mess, but I'm impressed with the way you can code in JS once it's setup. I'd messed with JS before, and went in with the mindset "This is going to be ugly, and I'm going to have to code everything from scratch" ES6's new syntax features, (most notably for of loops, arrow funcs, and map/filter), static type checking, and a python-like import system make this pretty cool! Lodash fills in the gaps.

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

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

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

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

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

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

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

Dominoes: Sep 20, 2007

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

Sedro: Dec 31, 2008

Dominoes posted:

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?

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

Dominoes: Sep 20, 2007

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

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

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

Dominoes: Sep 20, 2007

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

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

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

Dominoes: Sep 20, 2007

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

a witch: Jan 12, 2017

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

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

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

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

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:

{
  "name": "lynda-copy-course",
  "version": "1.0.0",
  "description": "A utility for copying downloaded Lynda.com courses from one machine to another",
  "bin": {
    "lynda-copy-course": "./src/index.js"
  },
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "./dist/lynda-copy-course"
  },
  "license": "MIT",
  "dependencies": {
    "ncp": "^2.0.0",
    "sqlite3": "^3.1.8"
  }
}

I'm running (from the root of the project) "npm install . -g". This works in so far as it makes lynda-copy-course available on my command line. The problem is that when I run this new addition to my path, visual studio opens up the index.js file - node doesn't run it.

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

camoseven: Dec 30, 2005; RODOLPHONE RINGIN'

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,
JavaScript code:
{
  "name": "lynda-copy-course",
  "version": "1.0.0",
  "description": "A utility for copying downloaded Lynda.com courses from one machine to another",
  "bin": {
    "lynda-copy-course": "./src/index.js"
  },
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "start": "./dist/lynda-copy-course"
  },
  "license": "MIT",
  "dependencies": {
    "ncp": "^2.0.0",
    "sqlite3": "^3.1.8"
  }
}
I'm running (from the root of the project) "npm install . -g". This works in so far as it makes lynda-copy-course available on my command line. The problem is that when I run this new addition to my path, visual studio opens up the index.js file - node doesn't run it.

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.

"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

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

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

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

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:

{ "bin" : { "myapp" : "./cli.js" } }

and

{ "name": "my-program"
, "version": "1.2.5"
, "bin": "./path/to/program" }

And the package that I was using as a reference has a bin value similar to mine above in its package.json:

JavaScript code:

{
  "name": "ncp",
  "version": "2.0.0",
  "author": "AvianFlu <charlie@charlieistheman.com>",
  "description": "Asynchronous recursive file copy utility.",
  "bin": {
    "ncp": "./bin/ncp"
  },
  "devDependencies": {
    "mocha": "1.15.x",
    "rimraf": "1.0.x",
    "read-dir-files": "0.0.x"
  },
  "main": "./lib/ncp.js",
  "repository": {
    "type": "git",
    "url": "https://github.com/AvianFlu/ncp.git"
  },
  "keywords": [
    "cli",
    "copy"
  ],
  "license": "MIT",
  "engine": {
    "node": ">=0.10"
  },
  "scripts": {
    "test": "mocha -R spec"
  }
}

...
...
Just noticed the "engine": { "node": ">=0.10" } entry here. Is that the difference?

# ? Apr 10, 2017 05:36

Sedro: Dec 31, 2008

It means your script located at bin/ncp needs to have that shebang line

# ? Apr 10, 2017 06:00

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

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

The Fool: Oct 16, 2003

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

Dominoes: Sep 20, 2007

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

MrMoo: Sep 14, 2000

Isn't the crappy situation of browsers not supporting ECMAScript import but everything else does?

# ? Apr 10, 2017 22:33

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

I've never had to do that. I'll look at in in more detail when I get home.

# ? Apr 10, 2017 23:14

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

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

The Fool: Oct 16, 2003

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
// assume a corresponding global variable exists and use that instead.
// This is important because it allows us to avoid bundling all of our
// dependencies, which allows browsers to cache those libraries between builds.

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

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

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

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

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

The Fool: Oct 16, 2003

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

necrotic: Aug 2, 2005; I owe my brother big time for this!

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

ddiddles: Oct 21, 2008; Roses are red, violets are blue, I'm a schizophrenic and so am I

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

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 12:08

geeves: Sep 16, 2004

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.

I guess what I'm saying is: Do whatever works for you, and if you find yourself running into performance issues, fix it then.

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

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›277 »