These are chat archives for ramda/ramda

26th
Mar 2017
Matt McKellar-Spence
@MattMS
Mar 26 2017 07:18
@m59peacemaker thanks for your futurize-* project links. :smile: Any chance you could briefly explain the benefits over https://github.com/futurize/futurize ?
Johnny Hauser
@m59peacemaker
Mar 26 2017 15:03
@MattMS depends on the context you're using it, I suppose. For small packages, I don't believe in exposing multiple functions unless you will definitely need most of them, and I don't believe in using es6 for them (yet)
My philosophy is to make everything as minimal, compatible, and simple as possible.
It's not so bad with es6 import, except that then one wonders what will happens with CommonJS
In other words, look at his package.json and look at mine.
I just like the minimal nature of it. You know it's going to work wherever you use it without having to figure out how the build is done and what it supports.
The only advantage of the es6/mono repo is that you can just install the one thing and import only what you need, then tree shake the rest
Johnny Hauser
@m59peacemaker
Mar 26 2017 15:08
Also, what if you're making a small package that needs to futurize a call? I wouldn't want the extra bytes of 2 other functions needing to be installed along with my package.
I'm obsessive :)
I'm working on a large library right now. We have an organization for it. It's a ton of functions all in one repo, but we're going to expose it as a mono package on npm that supports es6/import/tree shaking, or you can require the whole thing, like R = require('ramda'), or you can require('the-project/the-function'). So, whatever you do will work.
But, we're also publishing every function in it as its own package under our org namespace
and the org namespace is the same as the mono package
Johnny Hauser
@m59peacemaker
Mar 26 2017 15:13
require('the-project/some-function')
require('@the-project/some-function')
meaning that you can get whatever you want, however you want
That's the right way to do such things
I wish Ramda were that way, but Ramda also has some goals that make it less ideal for such purposes. It supports a lot of stuff that adds bytes / internal deps you wouldn't want to deal with if you just want a single function dependency
Like ramda-fantasy support and placeholders
Johnny Hauser
@m59peacemaker
Mar 26 2017 15:49
Just for the sake of evangelizing a little better
import R from 'ramda'
const R = require('ramda')
import { groupBy } from 'ramda'
import groupBy from '@ramda/groupBy'
const { groupBy } = require('ramda')
const groupBy = require('@ramda/groupBy')
// and maybe:
import  groupBy from 'ramda/groupBy'
const groupBy = require('ramda/groupBy')
would all be ideally possible
Can Göktas
@cangoektas
Mar 26 2017 19:33
Hi everybody. I feel like you all created something really special here and I would love to contribute. What are your current pain-points? What needs to be changed? Lots of open issues and I'm just not sure where to start. 🙂
Ryan Stegmann
@rstegg
Mar 26 2017 20:03
@cangoektas sharing code you've written with ramda seems to help