DRY - Don't repeat yourself
Let's extend it to DRA - Don't repeat anyone.
For fast-moving startups like eka.care, it is important to iterate fast and bring a delightful experience for users. Thus plugging all the already built things, gives us more time to focus on the product rather than reinventing things from scratch.
This blog will revolve around how the mind process should work while evaluating any library and tries to clear some myths on the same. Here are the five simple principles, which are crucial while rapidly bringing features for your users. These rules helped us in building seamless experiences for our doctors, where they can create rich prescription in less than 45 secs:
This is super important. Anything is built with intent, and libraries too. If your use case and the intent doesn't match, sooner or later you gonna be in a problem. Read about the library, what's the motive for it and to which problem it is offering solution.
e.g: If you are building a tab layout, don't blindly pick any carousel library just because it has swipeable functionality.
Tabs can be an extension of that carousel library, but NOT always, depending on how the library is structured. Tabs have a tab bar, selection slider, which moves as the user swipes. So if the carousel library doesn't expose relevant callbacks, it will be really hard to extend it for a tab bar. Another issue is, carousels are mostly for images and rarely deal with vertical scrolling. But in tabs, vertical scrolling is a prominent use case.Know what library offers and what NOT
By knowing about the capabilities of your assets, you can last long in the game.
It is recommended to go through the whole documentation once (at least on a high level). It can spark some product ideas in your mind 💡.
Not doing so, can end you up switching between different libraries frequently.
It is advised to make sure, the library has exposed significant methods, based on your need.
PS: Going through open issues is also part of evaluating the library.
After getting any good idea, what the library, one can end up neutralising the first point: If the carousel library seems easily extensible, then it's tab layout for you :)
The number of Stars is directly proportionally to popularity, it has NOTHING to say about how much percentage of your use case matches with the library intent. So it's OKAY to pass it and going with a little less popular one.
Sometimes we have found that libraries hosted on individual developer profiles are much more close to our use case than the one with thousands of stars.
See, the thing is, as a library transits from x ⭐ to x*1000 ⭐, it starts generalizing stuff (obviously to increase adoption). But if it is not solving your core use case, it is not for you.
You have to go through its documentation and even codebase to figure out whether it will work for you or not. No EXCEPTION here :)
At any point, you being a curious developer will think of extending that library to cater to your new needs. Now at this stage, if you figure out that this library is depending on some other external library, which has no support for your (significant) users (browser, mobile, etc). Then it's too late, now you will be juggling again to figure out a new library for your need.
Remember, every refactor comes with its own cost, time, and chances of introducing bugs have very high costs.
Get KYL approved before your code hits production 😉
While building for internet first users, we can't just show a loader and wait for huge library to get loaded. Every ms counts. If you are planning to use very tiny functionality to a big library, check if library supports selective imports?
Also, if you are thinking to extend that library, having a big size will increase maintainability on your side. Even which extending, there are chances to miss out on some cases, which will introduce bugs.
Click here for more stories about how we build our eka.care #ekaCares.
Click here if you’d like to build next-gen healthcare products with us. 💚
.jpg)
