Solving older frameworks issues using modern framework concepts: A Journey
Imagine you are standing at a movie ticket counter waiting your turn in a long queue to get tickets to your favourite movie. A long queue results in a long waiting time, even though the actual time to purchase a ticket is less. Now wonder if the movie hall opens up another ticket counter, the line will divide itself into two separate lines and the waiting time will be halved. Opening up yet another counter will make the queue even shorter reducing the waiting time even further.
At 1mg, we faced a similar problem recently, wherein the prescriptions that needed to be digitized had a larger queue than the actual digitization time resulting in a higher waiting time for the customers. This is a big problem for a startup that is looking to grow exponentially. Tackling this challenge was on priority, hence a solution similar to the above example was put in place.
Taking into account our problem and the currently placed code we faced a challenge to code our solution on a framework that is considered old by modern standards.
Coming to “which framework to choose” which has become an ever debatable topic doing rounds in the javascript community. Opinions and facts dominates the forums, linking graphs and adoption charts to show the superiority of one over another. In the end they are tools that helps in doing the job, one may be better than another in some areas but on a higher level a framework needs to achieve what it promises. Going back to an older framework and understanding it’s underlying ideology and philosophy takes you back into time and makes you appreciate the ease and help which are provided by today’s modern javascript frameworks. Here we share the challenges we faced during the project and how we overcome them using the concepts that today’s framework uses out of the box.
Challenge 1: Passing Data from Parent element to Child Element and vice versa
In Backbone JS, One can use a model (A key-value pair object) for passing data from parent view to child view. It’s the same MVC (Model-view-controller) approach that UI framework usually makes use of.
But Wait!! There is a short coming to this approach 🙈
As we know, passing of data/data binding is unidirectional only i.e from parent element to the child element which causes problem when we have to send data back to parent element from the child element. Unfortunately, there is no official Backbone JS documentation stating a preferred way of passing data from child to its parent. However, one way of achieving it is by using the concept of Event Bubbling in Javascript. We used the same concept to achieve our goal.
Here’s how this works 👨💻
In our code, every time any values get updated in the UI, the corresponding element triggers a custom event along with the changed data. A listener is listening for these events at each page which gracefully handles the event by updating the webpage’s global object with the updated values.Thus our original objective is achieved.
Challenge 2: Creating a centralized Global Object for storing state of the page
Next we had to let the user input some values and validate certain items before either accepting or rejecting the whole prescription and getting to the next task.
For the people familiar with Backbone JS framework, it lets you sync up your model with your server by calling out a sync method on the model which makes a network call to server every time a value gets updated. Normally we uses React Js framework which takes a relatively different and an efficient approach towards syncing data with the server. React JS uses the concept of State which is a global object with key value pair that holds up data relevant to a specific component. One can easily send the entire state object to the backend when the data needs to be submitted. This makes less network calls to the backend server, hence is a more viable option in our use case.
By overcoming the challenge above we were able to pass data from various child views to out root parent view where it was maintaining a global state object for the entire page. This way when the user wanted to submit the validated data, we only had to send the central global object to our backend server making just a single network call. Efficient, isn’t it? Yet, a pool of challenges awaited us in our journey further.
Challenge 3: Re-rendering our UI upon change in data
What React Js gives us out of the box, Backbone JS had our head scratching over. Re-rendering our corresponding UI upon any change in model’s value isn’t as straightforward as it seems.
Backbone follows a typical MVC model where an update in a UI triggers an update in the local model which then updates the UI. Here each view has its own model and no global central model is present, though a collection of model is allowed.
Our journey began from the following problem statement :-
Everytime a user refreshes or comes back to our page again we were showing an outdated value to the user because the browser was caching the views on its side.
Here is how we overcame this challenge 👊
For handling our re-rendering issue we tried various solutions ranging from refreshing the page again upon user visit, to making backend calls for all the values necessary to re-render the elements of the page. In the end, we settled upon disable the caching of our views on browser by making a new view instance with hydrated values from the webpage’s Global state object we were maintaining. This way we were able to keep our view in sync with our central global object. The solution was inspired from React JS very own implementation of state and re-rendering UI upon any change in its state value.
In conclusion this exercise provided us with a lot of insight on how javascript based frameworks have evolved over the past few years. Following were the learnings achieved over the course of this project.
- Frameworks are just tools to achieve our end goal, one thing that can be done in one can be done in another.
- Re-render of UI should not to be taken lightly on older frameworks.
- It is important to develop well thought out solutions rather than just making things work.
- Working with an open mindset, be open to experiment and learn new things on a regular basis(even frameworks), you will learn alot by failing.
If you like this article and learned something new, please give us a 👏 .
Do share it with people who could benefit from this experience. If you have any feedback or suggestions, or just want to drop a casual ‘hi’, please reach out at LinkedIn or Twitter.
