Application Development Meanderings

It can be confusing to move from javascript to typescript if you are not used to types. If you want to use more advanced react component creation techniques, it can be even more confusing. Passing Down “Created” Elements If you pass in elements, such as a message to display when there is no data, you need to pass in either a react element or someting you pass to JSX/createElement (see Pass in Elements for Your Component). If you already have an element that you created in the parent element, then you have an element you want to pass. You may just want to pass in something that is renderable. Should you pass in a RectElement or something more general that is renderable? What type should you use? If you think of the element you want to pass like children, then you can find the definition for what is passed is children by looking at some of the other definitoions. You’ll find ReactNode[] . // // React Nodes // http://facebook.github.io/react/docs/glossary.html ...

One problem with having such a diverse set of build and test environments is that the environments do not always play well together. Here's a simple example: webpack: Using DefinePlugin to define some DEBUG and API constants, set in the build environment based on prod or non-prod builds. jest: Since DefinePlugin "inserts" constants into the modules, these constants are only defined if you use webpack. This either forces you to use webpack for test builds which I'm not even sure how that would work, or you need to mock the webpack features in some way. That's one complaint. The bottom line is that using features in build/test tools that do not strictly "emit" file-based javascript to be consumed consistently across toolsets will cause issues like the above to occur. Of course, the test tools do try to some different environments but there is a limit to what they can reasonably do without becoming overly dependent on other environments. 

Typescript packaging If you are new to typescript the documentation may be a bit confusing about what it is doing around packaging your code. However, if you understand that typescript, sometimes, is a combination of transpiler, polyfill and packager, it makes much more sense. My pipeline is typically, typescript => babel => webpack. I use typescript as a transpiler, and sometimes it performs functions that babel does and sometimes things that webpack does. Webpack, and babel/typescript, add boilerplate to a bundled package when it bundles but it may be minor or significant depending on your target bundle size. Also, both typescript and babel can use global or "libary" polyfills to support different deployment models. I tend to use babel for transpiling down to the target js version because I'm able to specify browser versions in .babelrc as targets and it automatically figures out what to do. typescript can do something similar by targeting a specific jav...