Comments (10)
BTW, by dumping those into standalone files, you actually expose them differently than FPO does... because FPO actually curryMultiple's each API method, including (ironically) curryMultiple(..)
itself.
IOW, this works with FPO:
FPO.apply( {props: ["x","y"]} )
( {fn: foo} );
But with your exposing of apply(..)
, it won't. It'll have to be used as:
apply( {props: ["x","y"], fn: foo} );
That could be a gotcha for people reading code, to expect it to work the same as the methods from FPO. You might either change them to both be curried (you can do it manually), or at least note in the documentation that this difference exists, to prevent confusion.
from fpo.
Makes sense. I'd recommend bundling these two together then. :)
from fpo.
I've went ahead and extracted 2 of the functions I'm primarily interested in atm:
https://www.npmjs.com/package/@justinc/fpo-apply
https://www.npmjs.com/package/@justinc/fpo-curry-multiple
Thanks for the awesome library!
(they're MIT licensed and give attribution. If there's any other attribution I need to give in the repo / npm package - let me know and I'll add it).
from fpo.
As discussed in #1, the plan is to eventually have some sort of option for either importing only certain methods (ES6 modules style -- with tree shaking taking care of removing unused stuff) or customizing a build (lodash style).
But I'm just curious, given that the whole library (unminified) gzips to under 5k, which is pretty small, what's the particular motivation of wanting to split out specific methods?
from fpo.
Well, maybe it's just my lack of understanding with how these things are optimised via bundlers like Webpack.
I'm using these 2 functions in another "micro" lib, itself exporting a function (and I wanted to write this function "normally" and then give it the properties I get from apply
and curryMultiple
).
I don't want packages depending on this package to pull in all of FPO, when that lib could itself be pulling in all of Ramda - etc…
ah... I just saw your latest comment. Fair enough - I think I'll go with documenting it - or another small package which exports both of them. Basically, I'm just interested in the property of making my own functions "FPO" style (or "named argument" style). (in "rare" cases where the number of args gets a bit too much).
from fpo.
Also... even if "tree shaking" detects what I'm using from Ramda / FPO and pulls in only that code - I'm inclined to still prefer a solution which pulls in only the code I'm using on my dev machine too... it's just a personal preference - but yes, I'd agree that the "real" issue would be serving it to client browsers.
from fpo.
I've added a note and published so it shows up in npm (README).
Thanks again Kyle! Named args can be pretty handy :)
btw, I think I'll leave them as 2 separate packages. I don't mind that their behaviour is non-curried as long as I get to make certain other selected functions "multi-curried" + "named args" using them.
(I expect that this won't be a "big deal" if anybody else wants to do the same thing).
from fpo.
@getify , perhaps I can make a better case now that I've published what I had in mind... nothing special, just a single function I was using in a project which I thought might be re-usable and didn't want to have to think about re-implementing it:
https://github.com/justin-calleja/to-validation
That's depending on:
https://www.npmjs.com/package/@justinc/fpo-apply
https://www.npmjs.com/package/@justinc/fpo-curry-multiple
For a single function, it might make more sense why I do not want anything other than what it needs (not the whole FPO... nor the Webpack runtime for e.g.)
I've just familiarised myself a bit with rollup and am trying to cut out my @justinc
packages and depend on FPO directly, I would then like rollup
to tree shake any unused functions from FPO in the resulting bundle (which I intend to have in the UMD format, as well as a package.module
field pointing to my source.. which is using ES6 modules).
I'm not sure if there's a way to do this from rollup
but the plugin config below is not working (it's bundling all of FPO):
plugins: [
nodeResolve({
jsnext: false,
main: false,
module: true
}),
commonjs({
namedExports: {
'fpo': [ 'curryMultiple', 'apply' ]
}
})
]
It seems like tree shaking won't work unless the module I'm importing (FPO) is written using ES6 modules.
Re this issue #1
I don't think you need to write each function in a separate file. It might be possible to keep your code written the way it is (UMD), and transpile it to ES6 module exports (I've never done it this way, only the other way round, e.g. ES6 to CJS). Once you have that, you should be able to just add a package.module field on your built file.
from fpo.
Sorry I never responded here. Your suggestion of using ES6 modules as a transpilation target rather than a source is spot-on with my way of thinking. I am hoping to create a tool that can do just that, but I haven't built it yet.
from fpo.
Hey @getify no problem. I forgot (exactly) what this was about to be honest. I was just playing around with an idea.
Thanks for all the great JS resources you put out there! :)
from fpo.
Related Issues (16)
- Support ES6 exports for tree shaking HOT 4
- Unfortunate name choice HOT 1
- Rationale? HOT 5
- Breaking: Make curry accept list of mandatory arguments HOT 1
- interesting quirk with named currying HOT 4
- should we pick up some tricks/optimizations from Ramda? HOT 3
- Add: `composeN(..)` and `pipeN(..)`
- add `reduced(..)` sentinel for `reduce(..)` short-circuiting
- Avoid abbreviated named arguments HOT 8
- Should some named-args be renamed for more consistency? HOT 3
- do we need named-argument aware `compose(..)` / `pipe(..)`?
- add some more methods HOT 1
- reorg and improve build process
- Why do FPO.head and FPO.tail operate on Objects? HOT 2
- get istanbul code coverage working, add coveralls badge
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fpo.