This past year we've created a second version of our framework, ScaleJS 2.0. The framework is quite small out of the box, which gives the developer the flexibility in how it is used. Because of that, we've created a number of NPM packages that we think of as extensions to the core framework.
These packages are typically tools we've already created for past projects, but will most likely be reused in the future. So any developer using ScaleJS 2.0 can pick and choose what code they need to help build their fintech apps.
An example of a package we created is our slick-grid-wrapper, a wrapper we created for the Slick Grid library. The wrapper works by augmenting its native functionality, more specifically with advanced filtering and a column picker.
Although, we are still in the process of building these packages, below is a recap of the steps we’ve taken so far and the lessons we’ve learned along the way.
1. First we identified existing projects that had a need for our NPM package. We had an existing demo app with a grid but it didn't have advanced filtering or a column picker, both of which could be provided by our Slick Grid wrapper.
2. Then we copied and pasted all of the code related to the Slick Grid wrapper into our demo application. Then, we had to get it to work altogether. This was the most time consuming step for two reasons:
- We had to replace some existing code critical to our app's functionality
- Our newly-added code was not originally intended to be an NPM package so it had to aligned with our demo app. This resulted in many breaking changes that needed to be fixed.
Our focus was to simply "get it working" with our new code, so we ignored the features that the Slick Grid wrapper would provide.
3. When the most basic form of the Slick Grid wrapper code was working in our project, we dropped it into an NPM package. Before we went any further, we decided to make sure we could actually use the most basic form of this code as a package. Good thing we did this, as we didn't realize which dependencies were needed until we had to place the code in its own package.
4. After we had the package working in its basic form, we then enabled each piece of wrapper functionality while fixing bugs along the way.
Our next step is to examine the endpoints of our package to see if we need to modify it to make it more generic for other use cases. Stay tuned for another post once our NPM package is complete.
What's your experience building fintech apps with NPM packages?