Single source of truth in frontend tooling

[prastut]

There is a fine line between writing your own custom components vs using libraries when you are working in a startup that needs to move fast even though the code feels hackish.

There are obviously some clear benefits when using battle-tested libraries, most importantly not worrying about tiny details or third-party compatibility. I tend to lean towards libraries at the space and time we are in, but this issue is about documenting when our ideology for writing code becomes different from the way we write finally.

---

Using libraries that maintain their own state is problematic because:

• No control over the components.
• Mirroring back the component state back to application state. IMO I feel this is more problematic than the first point. Eg: when I click play in the video.js component, two things happen. The internal component state updates + I mirror the same state change back to the application. Let's say for some reason the internal component didn't update (some error in playing the video file). Now I have 2 versions of the same state.

I now understand why React puts heavy focus on the concept of "single source of truth" and therefore have special callbacks on HTML5 elements like <input> which essentially fall into the category of components that manage their own state.

Documenting the libraries that are being used that manage their own state. Though they don't give any error at the moment, I would really like to have more control over these components:

• video.js - mirroring it's state back to application

• react-id-swiper - used for creating smart swipe based components. I would still use it for the amount of sophisitication the API has especially the physics part which would be really hard and time consuming to code it ourselves.

[prastut]

Replacing video.js with https://github.com/zzarcon/react-video-renderer could be worth the effort.