rubico is very much a JavaScript library, and was born from my own needs as a JavaScript developer. I have tried my best to preserve the good work and idioms of more traditional fp'ers, but rubico did not come from another language or another set of practices. I would say what I'm doing here with control expressions in rubico more borrows from earlier work trying to abstract the query DSL of elasticsearch. That produced something like this
*{*$and:{*fieldA:vA,// term*fieldH:{$like:vH},// match (fuzzy)*fieldB:{$gte:lvB,$lte:uvB},// range*fieldI:$exists,*},*$or:{*fieldC:[a,b],// terms*path.fieldE:[a,b],// nested terms query*$geo:{lat:123,lon:21,distance:'50mi'},// geo_distance*},
Lodash's FP module
I wanted rubico to be less of a grab bag and focus more on absolutely necessary syntax. You could in some ways consider hasFlag as a new member of the syntax available to solve the problem of a command line interface. Also, I've left an option for a "grab bag" of sorts called rubico/x. Basically if you have a function you like (like lodash defaultsDeep), you could add it into rubico as rubico/x/defaultsDeep. Then you could import it like
rubico is very much a JavaScript library, and was born from my own needs as a JavaScript developer. I have tried my best to preserve the good work and idioms of more traditional fp'ers, but rubico did not come from another language or another set of practices. I would say what I'm doing here with control expressions in rubico more borrows from earlier work trying to abstract the query DSL of elasticsearch. That produced something like this
I wanted rubico to be less of a grab bag and focus more on absolutely necessary syntax. You could in some ways consider
hasFlagas a new member of the syntax available to solve the problem of a command line interface. Also, I've left an option for a "grab bag" of sorts called rubico/x. Basically if you have a function you like (like lodash defaultsDeep), you could add it into rubico as rubico/x/defaultsDeep. Then you could import it like