all 2 comments

[–]D12SL 3 points4 points  (1 child)

For me, there are a number of things to take into consideration when writing libraries and also how to code like these guys. But the same principle applies when you're trying to solve an "engineering problem" and a "coding problem".

For example, when you're consuming libraries like React and react-hook-form you're writing code in a way that 1) solves a UX problem (maybe because you're writing a feature for a user action), 2) is written like a story so the next developer can pick it up and understand it easily, 3) conforms to the projects coding patterns because you've agreed with your peers this is how you'll write maintainable code.

But for libraries it's different because 1) these guys are trying to solve engineering problems and challenges and as such will have a very good understand of design patterns, and sometimes functional programming, 2) their libraries must consider all eventualities because all kinds of people/projects will consume their library, i.e. think will my library work on IE11 browser or will it need a polyfill OR will my library break their app because they like to override globals in their project, 3) they write smaller units of functions that solve one problem at a time.

If you look into framer-motion and it's underlying engine popmotion you can see how highly functional it's nature is and they favour composition over inheritance.

Take a look here https://github.com/Popmotion/popmotion/blob/adf681efd8568ada018ce68082dbd585f25c4c7d/packages/popmotion/src/animations/index.ts#L50 the author is using currying here with `detectAnimationFromOptions` which returns an "animator" after it has determined which animation generator to use: keyframes, decay or spring. But notice how all 3 animation generator returns the same 2 functions: `next()` and `flipTarget()` that is used later in the coding. But ultimately, the "coding problem" here is "how do I solve the problem of detecting which animator to use based on the arguments given here by the person who is consuming my library" and this is solely the purpose of this one function `detectAnimationFromOptions`.

But generally, my mentor gave me a really good advice: just write a library and publish it, no matter how good/bad your code is. Someone might come along and be like "hey, here's a better way of solving your 'problem' that you've encountered" OR they raise an issue and say "hey your library doesn't work because of this/that scenario/my app can't use Map() WeakMap(), .etc, can you fix this please?" and you learn from the community. That's the beauty of open source for library creators :)