Why use JavaScript modules?

Common problematic characteristics of JavaScript without JavaScript modules

• global namespace pollution
  • far too many global variables and functions
• use of implicit globals
  • files referencing variables and functions defined in other files
• files with 100s of lines of code
  • to avoid implicit globals, everything could go in one long file
• lack of encapsulation
  • just a long list of un-grouped functions and variables rather than encapsulated chunks of cohesive state and behavior

How do JavaScript modules solve these issues?

• encapsulation
  • a file is a module; a module is a self-contained chunk of behavior and state
  • a module imports its dependencies rather than reaching for globals
  • a module's contents is private by default--to share something, it must be explicitly made public
• avoid implicit globals
  • the top of a module file has a list of dependencies (these statements are like using statements)
    • in ES6 modules, these are "import" statements
  • IDE support gives warnings of implicit globals to help ensure the use of import statements

Why ES6 modules?

• with other options available (e.g. CommonJS, AMD), why choose ES6?
• I chose ES6 since it's now a part of the ECMAScript standard

JSX is a syntax extension to JavaScript.

• https://reactjs.org/docs/introducing-jsx.html
• https://reactjs.org/docs/jsx-in-depth.html

the .jsx extension

• JavaScript files that contain JSX do not have to use the .jsx extension
• choosing to use the .jsx extension is a matter of team preference
  • some teams choose to use .jsx whenever a file contains JSX
  • it's also common for teams to just always use .js
• whatever the choice, be consistent

TypeScript is a Superset of JavaScript.

• it provides pre-compile type-checking
• it enables IDEs to provide more detailed intellisense with type information
• it enables IDEs to provide pre-compile time feedback for many kinds of errors that typically don't show up until runtime in JavaScript programs
• it can generate declaration (.d.ts) files
  • these files enable IDEs to get the same improved intellisense on regular JavaScript files
    • NPM packages developed in TypeScript can be compiled to JavaScript with these generated declaration files
    • this resulting package of JavaScript with Types can then be published as the NPM package
    • this enables regular JavaScript programs to utilize these NPM packages and get IDE support for type checking
• JSX
  • TypeScript supports JSX
  • if using TypeScript and JSX, you MUST USE .tsx extension
  • it's also worth being aware that behavior of certain TypeScript syntax is affected
    • TypeScript source: https://www.typescriptlang.org/docs/handbook/jsx.html

Jest testing Library

• https://jestjs.io/
• React recommends unit testing with Jest
• React also recommends react-test-renderer

Test Renderer npm package

• https://reactjs.org/docs/test-renderer.html

OPTIONS for unit test runners and debugging tools

• simple command line execution of scripts defined in package.json
  • npm run test
    • this does not debug, just runs the tests
    • terminal shows pass/fail results--or errors out
• ndb - debugging with ndb
  • https://github.com/GoogleChromeLabs/ndb
  • completely separate tool from Jest
  • a nice tool for a close-to IDE debugging experience for JavaScript unit test debugging
  • a shortcoming
    • trouble getting source mapped debugging
      • have gotten this so far, except in the actual test file
    • trouble getting breakpoints outside of the test file
      • so far, have only gotten breakpoints within the test file
• VSCODE
  • depending on installed extensions, vscode unit test debugging experience is best that i've found so far
  • when using Jest, the "Jest Test Explorer" is quite nice
  • vscode w/ "Jest Test Explorer" extension
    • a key to getting the extension to see the tests is setting up a workspace and adding the project to the workspace
    • great experience
      • extension: https://marketplace.visualstudio.com/items?itemName=kavod-io.vscode-jest-test-adapter
      • i do wish that i could make it use my build scripts--can't as of yet at least
      • nice test explorer, debugging with breakpoints in the original files
      • once i got it working it was really nice
      • a nice feature: "Flatten Explorer" (avoid deep tree of folder structure--just show list of tests)
      • tried other extensions--couldn't quite get them working right

Just a note on built-in .NET Core support

• there was a point a few years back where some really helpful features were supported
• over the next few years, support has been removed
• there is still a minimal features set available

SPA Nuget package services

• deprecated services: https://docs.microsoft.com/en-us/aspnet/core/client-side/spa-services?view=aspnetcore-5.0
  • obsolete as of ASP.NET Core 3.0, will be removed in .NET 5.0
• existing services: https://www.nuget.org/packages/Microsoft.AspNetCore.SpaServices.Extensions