Application Development Meanderings

typescript ambient declarations, global.d.ts, lib and typeRoot.md When using typescript, you may have global ambient declarations you need to add. For example, my HTML defines several variables prior to my main .js file being loaded and executed. The .js file, packed using webscript and written in typescript, needs access to those variables. Accesing the HTML variables is much like accessing “window” inside of a .ts file. The typescript compiler declares a window object for us and makes it available without import in our .ts files. We clearly need something like that. google searching did not yield alot of insight, but the key thoughts you need to know are: typescript reads all your files in your compiler path e.g. src then compiles the file you want to compile and output. typescript has a search path algorithm that is used when importing modules. This search path is not relevant to solving the global ambient problem. Global ambient can be declared in a g

If you use typescript with react you may wonder what the right signature is for your “properties” interface. Obviously, your component will have few to many specific properties that reflect your domain. However, you may wish to also provide for the ability to add other attributes, such as those valid for a div property. In other words, you want to extend your props interface with that of the properties from a div element. How do you do that? There are really two issues: How do you extend your props interfaces How do you filter the props once you receive them to just those that apply. Extend Your Prop Interface or Use Sum Types It’s not uncommon to see interface Props { className ? : string yourProp ? : number } with the idea of using it in class MyComponent extends React.Component<Props, any> somewhere. If your component will have an outer div, you may also pass in a react element so that its configurable. But let’s say your outer element is a div and you wan

We would like to create a flexible set of functions for rendering a view on checkboxes. Many libraries try to take “control” of the rendering process and introduce brittleness into the component by making too many assumptions and then trying to provide too many “options” to allow you to customize the more monolithic comopnent. By breaking apart our functions into smaller ones, while offering defaults with all the bells and whistles, we can make a much more flexible library that can be used in many different scenarios. You can use ramda and recompose “in the small” assuming you are using it elswhere in your library that justifies its inclusion in your bundle. Here is a simple example of how we can use these extra tools to create a very simple, non-aria enabled check box list. It is not optimized for large lists either i.e. its not “virtualized.” import React from "react" import { defaultProps } from "recompose" import R from "ramda" import {

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