Posted on

Using theme specific keybindings in VSCode to improve productivity

I have been using VSCode as my primary editor for a couple of months. However it has been a recurring pain point for me that we have to switch back and forth between the arrow keys and primary rows when editing code.

The most popular solution for this seems to be the vscode vim plugin, and I tried adapting to it despite not being a vim user. While I got comfortable with the primary vim keybindings in a week or so of continued used, I continued getting the feeling that it was not really well integrated with VSCode.

Along with general performance issues and lagginess, the biggest problem for me was that often when navigating and editing rapidly the keystrokes would be applied out of order. This really breaks the flow when rapidly typing and after a month of usage I started looking out for an alternative.

Turns out a very simple alternative is to simulate modal editing through VSCode themes.

While I liked vim’s modal editing, not being a longtime vim user, I kept longing for a visual indication when switching modes. A trivial solution here is to just use different vscode themes along with the settings cycler extension.

With this extension enabled, we can have a single command to switch between two themes:

Now, we can define keybindings that are active only in a specific theme using the when clause.

This is somewhat verbose because VSCode only allows json for configuration (which I think is a bad idea), but nevertheless it gets the job done.

Now, when we press ctrl+0 and switch to Monokai theme, we can use i,j,k,l as our arrow keys.

We can of course extend this further and define more keybindings for selection, jumping to start/end etc.

Once arrow keys were no longer needed for primary navigation, I have been using them for switching focus across editors in different split panels and moving the editor around between split frames (a common but infrequent operation).

This has worked out quite well for me so far.

Posted on

Exposing the type of a typescript class while hiding the implementation

When we define a typescript class, we are actually defining two things, a constructor function, and a type. The instances constructed using the constructor defined by a class will have the type of the class.

One might wonder, if it is possible, say from a library, to expose only the type of the class and not the actual type constructor. The goal here may be to prevent direct instantiation of the class, or prevent consumers from monkeying around with the prototype chain of the constructor.

Of course, direct instantiation can be prevented using private constructors, but that is only if the consumers are using typescript. A consumer using plain javascript, or who is liberal with use of any is more than welcome to instatiate the class directly.

One obvious approach is that we could define an interface, make our class implement the interface and expose just the interface.

This works, but requires quite a bit of extra effort and duplication of signatures (assuming that interface is being created just for this purpose only).

But, what if we could just strip out the run time entity (constructor function) of a class definition, and just retain the type of the class. This is indeed possible and very easy to do.

We can just make an interface which extends a class (and doesn’t add anything extra).

Exporting this interface provides our typescript consumers access to the type of the class, but doesn’t provide anyone access to the constructor function or the prototype chain.

If we are not ever exposing any instance of this class, and the class is for internal use only, we are pretty much done here.

However, in case we are exposing instances of this class, then we are not finished, because, any instance of the class also facilitates access to the constructor through the constructor property (which can be overriden) and the prototype chain can be accessed through Object.getPrototypeOf or the controversial (and legacy __proto__ property.

The safest way to completely hide the implementation of prototype chain while exposing the instances is to wrap the instances in a Proxy that delegates method access and property access to the underlying target instance.

Posted on

Using an SVG grid background for aligning elements in web page

One of the recurring annoyances when designing websites is ensuring alignment of elements on a web page.

Most design applications have the provision of an overlay grid. With very little effort we can add a simple grid to any web page and use it to ensure alignment of elements.

As illustrated in this codepen we can create a grid using a few lines of SVG:

We can use an extension like stylish and save this snippet to apply the above css grid as a background image to html.

So now whenever we activate this style and add grid-backdrop-enabled to html, the grid will show up as a backdrop against the transparent body and we can use it to check for alignment issues.

We can always adjust the SVG to tweak the appearance of the grid. Here is a slightly adapted one which highlights 5px, 10px, 50px and 100px boundaries with different colors:

Posted on

Simplifying generics-heavy typescript code using Container Interfaces, Extractor Types and Companion Namespaces

Writing generics-heavy code code in Typescript can sometimes be arduous, especially because typescript doesn’t facilitate higher kinded types at language level.

So, a function that accepts multiple arguments of generic types often has to accept type parameters of all these generic types in order to retain type safety:

This can get cumbersome fast, especially when the parameterized types have constraints on the type parameters because now these constraints also have to be replicated:

Continue reading Simplifying generics-heavy typescript code using Container Interfaces, Extractor Types and Companion Namespaces

Posted on

Integrating Google diff-match-patch with AutoMerge.Text

This post outlines the use of Google’s diff-match-patch library to generate patches that can be translated to operations against an AutoMerge.Text CRDT for situations when deriving the operations directly from user interactions is cumbersome.
Continue reading Integrating Google diff-match-patch with AutoMerge.Text

Posted on

Uploading files to MongoDB GridFS via Apollo powered GraphQL API

GraphQL multi-part request spec outlines a specification for multipart form requests in GraphQL. Jayden Seric, the author of the spec, has also authored two libraries apollo-upload-client and apollo-upload-server which makes it effortless to integrate file uploads in Apollo Server.

GridFS is a simple file system abstraction on top of MongoDB. This facilitates storage of large files (beyond BSON document size limit) in mongo database.

This post outlines the minimal integration required to save the files uploaded through the GraphQL API to GridFS.

Continue reading Uploading files to MongoDB GridFS via Apollo powered GraphQL API

Posted on

Getting productive with selection and navigation in Emacs

This post is intended to primarily benefit people coming from other, so called “modern” editors to Emacs. Emacs veterans are likely to find most of the tips here very elementary.

I have observed that many programmers habituated to newer editors have many implicit assumptions about editing workflows which simply don’t hold true within Emacs environment and this prevents them from being productive to the fullest extent.

This post primarily focusses on how getting familiar with the concept of marks and regions in Emacs can result in productive workflows. These concepts, coupled with a few extensions can enable much more pleasurable code-editing workflows not easily achievable in more prevalent “modern” editors.

Continue reading Getting productive with selection and navigation in Emacs

Posted on

Javascript Async/Await with arbitrary Thenables

Usage of C# inspired async/await syntax (Now a stage 4 proposal) is now fairly mainstream in javascript, and native support is available in major browsers and Node.

Most of the times we await on promises (typically returned from async functions), however, it is relatively less well known that await works on arbitrary thenables. By thenables we mean any object with a then function member.

This post covers this usage, and explores some scenarios where it can be interesting.

Continue reading Javascript Async/Await with arbitrary Thenables