The latest articles on DEV Community by Poladarn (@jituanlin). https://dev.to/jituanlin https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F246187%2F2a36eb03-1b64-464b-9829-d8822c6a9ae6.jpg https://dev.to/jituanlin en Poladarn Fri, 11 Feb 2022 06:55:44 +0000 https://dev.to/jituanlin/a-light-library-for-pipe-style-programming-5dlh https://dev.to/jituanlin/a-light-library-for-pipe-style-programming-5dlh <h1> A light library for pipe style programming </h1> <p>Pipe style programming is a powerful tool for dealing with data processing.</p> <p><a href="https://ramdajs.com/" rel="noopener noreferrer">Ramda</a> is the most popular library for that.</p> <p>And <a href="https://github.com/gcanti/fp-ts" rel="noopener noreferrer">fp-ts</a> also excels at that and provides many useful ADT(Algebraic Data Types).</p> <p>However, they may also introduce other things you don't want.</p> <h2> The price of Ramda </h2> <p><em>Complex type definition.</em></p> <p>Due to the dynamic nature of Ramda, TypeScript needs to work very hard to describe it and end up with a complex type definition.</p> <p>How many times have we needed to dig into the source type definition to find out<br> why does type inference not work, even knowing that the logic of the code is correct?</p> <p>To me, TypeScript is more of an enemy than an assistant when I use Ramda.</p> <p>Ramda type definitions are fragile for several reasons:</p> <ul> <li> <code>pipe</code> function is designed to accept data as the last argument. That makes type inference difficult, especially when combined with overloaded functions.</li> <li>Currying. You can pass arguments in any way you like in Haskell. It's sweet but makes type description difficult.</li> <li>Function overload. Almost every function in Ramda is overloaded. TypeScript has difficulty choosing the right overload in the <code>pipe</code> function.</li> </ul> <h2> The price of fp-ts </h2> <p>fp-ts is great but introduces many functional programming concepts that many teams are unfamiliar with.</p> <p>That makes team collaboration may require too much learning cost.</p> <h2> pipeable-es-fns maybe another choice </h2> <p><a href="https://github.com/jituanlin/pipeable-es-fns" rel="noopener noreferrer">pipeable-es-fns</a> proposes another solution:</p> <ul> <li>Embrace pipe style programming.</li> <li>Simple type definition is easy to understand and debug.</li> <li>It just ports ES6+ functions to curried version, that's all.</li> </ul> <p>The idea of pipeable-es-fns is to introduce minimal things for adopting pipe style programming.</p> <p>Instead of selling <em>point free style</em> or <em>Monad</em> to the team, it should be easier to convince a team to use the curried ES6+ function.</p> <h3> Design philosophy </h3> <p>pipeable-es-fns adopts a few design philosophies to make type and usage smooth:</p> <ol> <li>Just curried the ES6+ functions and try to keep others untouched.</li> <li>Just use the TypeScript official type definitions of ES6+ functions.</li> <li>Just delegate the implementation to the native ES6+ functions for avoiding runtime.</li> <li>Unlike Ramda, the pipe function accepts data as its first argument for better type inference.</li> <li>Organize the functions in a namespace rather than function overload for better type inference.</li> <li>Doesn't support deprecated methods intentionally.</li> <li>Encourage to specify the optional arguments implicitly.</li> <li>Encourage to use one function in one way only.</li> </ol> typescript functional ramda lib