Posts tagged javascript

Apply, Apply


While going through Jasmine’s source code, I came across a weird idiom: What in the world is ? I decided to find out for myself. As a refresher, let’s write a function that simply prints out its and . When invoked as a method on a function, executes its caller with its first parameter as the caller’s , and its second parameter as an array of arguments as the caller’s argument list. The parameters to can be anything, even primitives, as demonstrated below: prints: To preserve our sanity later on, let’s see in more detail by defining a wrapper around : Running with this modified version of prints: So what does it mean when you call again on itself, as in ? Calling on means that will execute , and since needs to be executed in the context of a function, the first parameter must be a function. (I only know this from working backwards from the interpreter’s errors, go figure). In this case, since in is the primitive , is obviously not a function since it doesn’t inherit from . Now that we know that the expects a function as its first parameter, let’s try putting there: Okay, so at least it’s a different error now. Why is complaining that its argument list (the second parameter) has the wrong type? That’s because its trying to call ! Don’t forget that expects an array as its second parameter. So I guess we can wrap the second in an array: So it finally works! Wait, doesn’t this look… familiar? It should, because what its doing is exactly what is doing (see above) - executing with as and its arguments as . And isn’t it stupid that we’re mentioning twice? What exactly does the first even do? Let’s get rid of it: It turns out that it doesn’t matter which function calls , because the only function that is going to be executed is ’s. ’s original context is irrelevant (imagine it as behaving as a static method). It’s just there to facilitate this process by helping “promote” the first parameter (the function) into the executing function itself. Maybe its a little clearer if you remove from the equation: So there you have it. And after all this trouble, I still don’t actually know why Jasmine uses this idiom. Instead of It seems the following is equivalent: Bonus What happens if we chain more than 2 s together? Looks like doesn’t even get run at all. This is puzzling at first, but makes sense when you think about it - ’s original , , has been “diverted” to (remember when I said above that ’s original context is irrelevant?) Thus, when…

Setting Up A Test-Driven React Project From Scratch - Part 1: webpack


You will learn how to scaffold a React project from scratch with Karma and webpack. I’ve tried to make it as unopinionated as possible. Hopefully, once you understand the rationale behind each of the moving parts, you can roll your own or use one of the many templates available elsewhere. At the end of this part, you would have set up webpack with: Source maps with the flag Let’s create a simple project that allows users to create reviews of beer and populate a list. We’ll call it Beerist. Let’s create a project directory: Initialize a by filling in the fields as appropriate: Create a directory that will hold all our source files. Within , create a directory and a that will act as an entry point for the app. Our directory now looks like this: In , let’s just write a simple one-liner for the purposes of testing: webpack webpack was born as a agnostic module loader. Its Motivation page introduces itself quite nicely. Since its inception, webpack has grown to encompass some elements of build tooling as well, which greatly reduces the need for Gulp or Grunt. We’ll install webpack first so that we can write our React files in ES6 (or ES2015, or ES6+, or ES7, or whatever they call it nowadays) from the get-go and have webpack run the files through Babel to transpile our ES6 down to ES5. We’ll also install webpack’s dev server so that we can serve the files locally using a built-in Express server and sockets (for hotloading): This creates a directory if it hasn’t previously been created, and downloads the latest version of all the modules specified from . saves it as a development dependency entry within your : Create a file called , which tells webpack what to do: The config starts off by requiring and , which is a built-in Node library that provides utility methods for manipulating file path strings. In particular, we use together with the “global” variable to resolve relative file paths to absolute ones. Now how do we run webpack and/or its dev server? If you’ve installed webpack and/or webpack-dev-server globally, you can simply run or on the command line to fire it up. Else, you can call it from an npm script inside : Now, we can run or (check out the difference between the two for yourself). Our directory should look like this: If you open , you’ll see some crazy stuff that webpack is doing to tie all your dependencies together. Of course, you’ll see your source code - all the way at the bottom: To see it in action in the browser though…

Topick - JavaScript NLP library to extract keywords from HTML documents


I recently wrote Topick, a library for extracting keywords from HTML documents. Check it out here! The initial use case for it was to be used as part of a Telegram bot which would archive shared links by allowing the user to tag the link with keywords and phrases: This blog post details how it works. HTML parsing Topick uses for HTML parsing. By default, Topick will pick out content from , , , and tags, and concatenate them into a single document. Cleaning That document is then sent for cleaning, using a few utility functions from the library to: Expand contractions (e.g. from I’ll to I will) Remove interpunctuation (e.g. ? and !) Remove excess whitespace between words Remove stop words using the default stop word dictionary Remove stop words specified by the user Stop words are common words that are unlikely to be classified as keywords. The stop word dictionary used by Topick is a set union of all six English collections found here. Generating keywords Finally, the cleaned document can be used as input for generating keywords. Topick includes three methods of doing so, which all relies on different combinations of library functions to generate the final output: The method relies solely on the method to generate keywords/phrases based on frequency. The generated words or phrases are then sorted by frequency and filtered (those with frequency 1 are discarded). The method relies on the method to guess keywords or phrases that are capitalized/don’t belong in the English language/are unique phrases. There’s also a frequency-based criterion here. The method combines both by running both and and merging their output together before sorting them and filtering them. This method is the slowest but generally produces the best and most consistent output. Custom options Topick includes a few options for the user to customize. ngram The method defines options for n-gram generation. min_count is the minimum number of times a particular n-gram should appear in the document before being considered. There should be no need to change this number. max_size is the maximum size of n-grams that should be generated (defaults to generating unigrams). progressiveGeneration This options defaults to true. If set to true, progressiveGeneration will progressively generate n-grams with weaker settings until the specified number of keywords set in maxNumberOfKeywords is hit. For example: if for a mincount of 3 and maxNumberOfKeywords of 10, Topick only generates…

JavaScript Object Creation and Prototype Chains


There are 4 ways to create new objects in JavaScript: Object initializers, also known as literal notation Constructors ES6 classes Depending on which method you choose, the newly created object will have a different prototype chain. 1. Object initializers Objects created in this manner will have as its top-level prototype: Arrays and functions also have their own literal notation: In these cases, ’s and ’s prototype chains will be and respectively. 2. takes in an arbitrary object (or ) as a first argument, which will be the prototype of the new object. Thus, ’s prototype chain is: is actually quite special because any arbitrary object can be specified as the prototype, so we can do otherwise nonsensical things such as: In this case, ’s prototype chain will be: 3. Constructors When a function is invoked with the keyword, as in , it behaves as a constructor function, which means the following things will happen: A new, empty object is created, whose prototype is Thing.prototype (the prototype object of the function object) The body of the function is executed, with its set to the new empty object The return value of the function is the result of the expression, unless no return value is specified, then the new object is returned To highlight the fact that the property object is distinct from the object to which it belongs to, notice the following: If we think of as simply an object, this shouldn’t come as a surprise. In fact, if we were do something like this: Thus, ’s prototype chain looks like: and not ES6 Classes Prototype chains in ES6 classes behave almost exactly like constructors (that is because classes are syntactic sugar around constructors): Thus, ’s prototype chain is: And of course, as mentioned earlier, classes really are just syntactic sugar for constructors: See footnote for a little more detail on how subclassing with actually works and how it affects the prototype chain between the subclass and the superclass. I’ve used here for better readability, but you can also substitute it for its inverse, , like When I mean “a”, I actually mean any arbitrary function. Of course, functions meant to be used as useful constructors should look a certain way. And another optional object as a second argument that specifies property descriptors. Part of Babel’s transpiled output for includes a function, the full body of which is below: explicitly creates the subclass’s prototype object using , specifying the super class’s prototype as…

The Browser DOM


October 10, 2019: I haven’t gotten around to porting tables over, yet, so some content may look broken. The DOM, as implemented in browsers, is a model to represent a HTML or XML document as a tree of nodes, and presents an API to access and manipulate these nodes. There are twelve kinds of nodes, but two of them are used the most - element nodes and text nodes. HTML tags are represented as element nodes, while the content inside these tags are represented as text nodes. In a typical browser environment, every node is represented as an object (with properties). The object contains properties to access these DOM node objects. The root node can be accessed with . Another example is the body, which can be accessed with . In the DOM API, elements which are not found, or referenced before they are rendered are : DOM Traversal There are several ways to move around the DOM tree. |--- | Direction | Method |-|- | Up | | Down | , which includes all node types, and , which includes only element nodes | Left/Right | , DOM Search Aside from traversing, there are also methods to access nodes in the DOM tree directly. They are called on the object, as in : |--- | Method | Description |-|- | | Find a node by its | | Find all nodes with the given | | Find all nodes with the matching HTML attribute | | Find all nodes with the given . Understands multiple classes | , | Find the first node/all nodes that matches the given CSS3 query, respectively and offer more powerful queries, but are less performant than the other methods. All these methods that return multiple nodes in a , except , are live, meaning that they are automatically updated when the document is changed. XPath Another way to search through the DOM is using XPath. DOM Node Attributes and Properties Since DOM nodes are represented as objects, they have properties, just like JavaScript objects. These properties include implementations of the various standard DOM API interfaces, which are common across all nodes. Some properties are read-only, while others are modifiable. Some important ones are listed below: |--- | Property | Description | Read-only |-|-|- | | ID of node type | Yes | , | Name of element nodes | Yes | | Contents of element nodes | No | | Contents for other types of nodes except element nodes | No Additionally, each type of HTML DOM node has its own set of standard properties. MDN maintains a comprehensive reference of all these DOM object types, for example, the DOM object. HTML…

JavaScript Timers


Timers in JavaScript are used to schedule functions to be called at a later time. It does so by setting up a timer which, when it’s done counting down, places its associated function into the environment’s event loop. As such, guarantees that the function won’t be fired before its specified time, but it cannot guarantee that it will be fired at that specific point in time too - if event queue has other functions waiting to be executed, then it will be delayed. These timer functions are methods on the object and can be invoked as is: Functions scheduled with can be cancelled with : and have cousins which execute their functions in regular intervals, called and . Debouncing Timers in JavaScript can be used for debouncing to prevent event handlers from being invoked too frequently. There are two effects that can be achieved here: To invoke the event handler after a pause in event firing To invoke the event handler at slower periodic intervals An example of the first effect: We clear the timeout to reset the timer. An example of the second effect: We check if is true fist before creating a scheduled function. When the scheduled function fires, it resets to false.

new-Agnostic JavaScript Constructors


Constructors in JavaScript have gotten a bad rep because there’s nothing stopping the unwitting programmer from doing something like this: I wrote comprehensively about object creation here, which may be useful to read as a prerequisite to this post. This tip from Item 33 of Effective JavaScript by David Herman makes your constructor behave as intended, regardless of whether the keyword is present. The first method: An alternative method to save that extra recursive function call:

Initial Form Values with redux-form


Caveat emptor: I’m currently using of . As with most things on the bleeding edge, this post will probably be irrelevant in a few months (or weeks). There’re a few reasons one may need to have form values initialized upon render - edit forms, or default values. In vanilla HTML, one would simply do: It’s a little different in JSX. In JSX, Facebook recommends the following way. To set initial form values in that are actually initialized in the Redux state, one needs to pass in an object with a main key and field key-value pairs as props to the component: If all goes well, you’ll see the initial values being loaded into Redux state upon initialization, which can be submitted (to ) right away:

Route Organisation with Express 4+


Caveat Emptor: As far as I can tell, this routing functionality will continue to work in Express 5, which at this time of writing is still in early alpha stage. Read the Express 5 Upgrading Guide here. Also, in the Nested Routes section below, I mention passing the option the method - this was only introduced in Express 4.5.0. The class was introduced in Express 4 to allow developers to instantiate routers as standalone modules with their own middleware and routing systems. For me, the greatest benefit is that this affords more flexibility and makes it easier to manage different combinations of middleware of varying specificity. This simple example gives a bird’s eye view of the different components of a working router implementation: At this point, the active routes would be: How I Organise my Routes Now, with a big app, we can split its many routes into different files, and instantiate/mount them neatly. This is great if you’re intending to be RESTful, because the organisation will come quite intuitively. I’m assuming a directory structure like this, where apples, oranges and pears are our resources: In , all we have to do is bootstrap the routes: In , we require each route file iteratively. Take note that usual routing precedence rules apply - both the file order as well as the route order inside a file matters. We can DRY it up even more by getting the file path from the mount point (or the other way around): There are many different ways to specify middleware for one or many route files. Here are some ideas: We can run multiple separate loops: We can even use regex (regex for flex!): Within a route file like , we can specify a middleware specific to the routes inside the file: And last but not least, if you only want to apply middleware to a single endpoint, you can do that too: Well, I did mention flexibility, didn’t I? Nested Routes Since we’re on the topic of RESTful, how can we do nested routes? Let’s say pineapples is a resource nested within apples, so we’ll want to have routes that look like: and so on. You can add nested routers as middleware. The key is to add to the Router factory so that the nested router can access the params from its parent router, which in this case is . In , it’ll look like this: Of course, if your app is really complex, you can put nested route files inside folders: and change the code above to reflect this file structure.

MVC Organisation with Express and Thinky


I wrote an example to demonstrate a way to organise your Express app in a MVC manner without resorting to complicated frameworks. Check it out here. This particular example is as barebones as possible. In particular, there’re no explicit view layer to speak of - we’re simply returning JSON. We could have implemented, for example, server-side rendered React/Redux into this example, and I intend to do that in as a separate example. There are a few concepts I want to talk about here: Model files Controller files First, we import so that we can use , which greatly simplifies working with promises and is the main reason behind the leanness of the code. Then, we import and to create the main Express object, and to parse the body of requests that are sent in either or JSON format. Then, we require the file, which contains the connection details for RethinkDB. We inject the config object as a dependency to , which creates the connection to RethinkDB and bootstraps our database schema and table objects. I will be using this pattern a lot more throughout the example. In , we define the entire schema, just like in Rails. I will defer the details of the syntax to thinky’s documentation. Note that this file can swapped out for any other ORM if you want (Sequelize, etc). After the schema is defined, we pass the thinky database objects to the model files: As a matter of convenience, I chose to pass all the models so that model methods can reference other database objects as well. Model Methods Model methods serve as a way to encapsulate ORM logic and make it reusable. Even though ORMs themselves already offer a layer of abstraction on top of the database, I prefer having model methods as an additional layer to meet common needs in your application’s business logic. Model methods are also handy in case you ever want to swap out the ORM for another one down the road. As an example, let’s look at the User model: A user has and methods, which behaves like and in Rails. The method is simply a thin wrapper around the thinky method, while wraps around the and thinky calls. This is especially notable because using constructor functions () is generally a bad idea (a questionable design decision on thinky’s part), but wrapping it around our model method limits the potential damage it can cause. Routing Back to , the routing is initialized by passing in the Express object and our models. The routes are found in , and is designed in a way as to mimic…

Pretty Form Validation with Redux Form


I made a nice and unobtrusive animation for form validation with redux-form: a To implement it, I made a component: The CSS for the component is surprisingly simple: The style is for overriding the browser’s default border styling, and can be left out if you already have existing border styles for your inputs. The gives a bit of spacing between the indicator and the text in the input. It’s important to note that, for the width of the input to stay fixed even as the border is transitioned in, you need to make sure that your is set to . Paul Irish’s CSS snippet works like a charm: Now we can use it in a redux-form component like so: 🙌

Agnostic HTTP Endpoint Testing with Jasmine and Chai


In this post, I’m going share my strategy for endpoint testing. It has a few cornerstones: It should test against a running server by sending HTTP requests to it, instead of hooking onto the server instance directly, like supertest does. This way, the strategy becomes agnostic and portable - it can be used to test any endpoint server, even servers written in other languages, as long as they communicate through HTTP. Each suite should be written as a narrative. To this end, BDD-style testing is very suitable. As an example, consider the narrative desribing the authentication flow for an app: I register as a user, providing a suitable email and password. The server should return a 200 response and an authentication token. Then, I login using the same email and password as earlier before. The server should return a 200 response and a authentication token. I login using a different email and password. This time, the server should return a 401 response. If I register with the same email as before, the server should return a 422 response and an error message in the response body indicating that the email has been taken. A few points to take note of: Even though the strategy is meant to be as agnostic as possible, you need to find a way to run the server with a empty test database, and then have some (hopefully scripted) way to drop it once the tests are complete. This part will depend on what database adapter/ORM you are using. I will share my solution for an Express server backed by RethinkDB later. Remember that the database is a giant, singular hunk of state. If you’re going to be adopting this style of testing, there is no way around this. You’re not just going to be running GET requests - you’re going to be running POST and PUT and DELETE requests as well. This means that you need to be very careful about tests running concurrently or in parallel. It’s great to have performant tests, but don’t trade performance for tests that are easy to reason about and which reveal clearly which parts of your app are breaking. I tried Ava first, and was actually halfway through writing the test suite for a project with it. I really liked it, but Ava was built for running tests concurrently and in parallel. There came a point where the test suite would fail unpredictably depending on the order in which the tests were run. Although it’s possible to run Ava tests in serial, I felt like I was fighting against the framework. I also considered Tape, but I consider Ava to be…

Exporting ES6 Library Modules as Global Scripts with Webpack


After authoring a library (Remerge) using ES6 style modules, aside from consumption with , I also wanted to release it as a standalone script so that users could use it by simply including it with a simple script tag - well, if they wanted to, at least (appealing to the lowest common denominator here heh). The Scenario So I wanted to be able to do something like this: Notice that both scripts have a slightly different export pattern. In my code, I wrote such that it was a default export: and as named exports, spread across a number of files (tackling the general case here): The Problem The problem is that, as it is, bundling these ES6 modules will result in objects that look like this: which is technically usable, but to use it would look like: which is a real PITA for ensuring a consistent API. The Fix The fix for this is simple: simply write a file that imports those ES6 modules the ES6 way, but exports them in nodeJS style. Webpack will then handle them correctly! For the top-level function export, simply export the function as is: For the object whose properties should be utility functions, the solution is similarly straightforward - simply create an (in this case anonymous) object whose properties are those functions: For my library, I’ve placed these “helper” files in a folder, as their sole purpose is for Webpack to generate the script files. You can place them anywhere it makes sense. The Webpack configuration for handling this is very simple (as far as build configs go): Then you can use them as shown in the HTML snippet above! For an actual live example of this in action, check out my library Remerge.

Circular References in GraphQL Type Definitions


When defining GraphQL types, it’s common to run into situations when two types reference each other. This is a problem because one type will be undeclared or undefined when the other is evaluated. To fix this, the reference JavaScript implementation allows us to indicate the fields using a function that returns an object, instead of a plain object. This function is lazily evaluated during runtime, so we will not run into problems with the interpreter.

Exposing React Performance Tools in the Browser Console


The React docs on Performance Tools is quite lacking as to how it should be used, so I had to do some digging around to figure out how it worked. It turns out doesn’t work in component lifecycles, raising an ugly internal error that hasn’t been properly dealt with yet (see this issue for more details). This prevents us from doing some things like: Calling and measuring performance repeatedly. Using to measure between arbitrary points in deeper parts of your component hierarchy. I solved these problems by exposing React’s performance tools in the browser. There are a few ways to do this. If you’re using webpack, you can use , which allows us to attach modules to the global object: You can then start measuring in the console at any time: and you can call in a component lifecycle method: or in the browser console: and the rest of the printing methods do.

Data Structures in TypeScript


Took some time off this weekend to learn some TypeScript, and reimplemented some data structures as practice. I don’t think I’ll continue to use much TypeScript moving forward, because it seems to promote the classical inheritance style of thinking in a language that doesn’t need or want it. TL;DR: Prototypical/concatenative inheritance is much nicer than classical inheritance. That said, first-class support for TypeScript in Visual Studio Code is quite awesome. While implementing the data structures, I came up with a TypeScript/prototypical hybrid style for writing object factories. In this hybrid style, the only place I’m writing any TypeScript is using interfaces for prototypes. Let’s take a class for example: I return a object whose prototype is using , and its initial state using . This style allows VSC to shout at me if the prototype doesn’t implement the interface correctly. It’s nice to have, but not worth switching over to a TypeScript workflow from the Babel workflow that I’m already used to.