jonlaing / rationale Goto Github PK

This is pretty self explanatory... Suggestions welcome!

It would be great if a distribution of rationale could include the built js files within it.

The reason this would be useful is for publishing JS packages that depend on rescript code, if the built js files are included within the package, then the JS code can reference the built files within rationale, rather than needed to run rescript build -with-deps to create those dependencies (which can't be asked for when publishing a package).

The other alternative is include rationale inside the distribution of my package. However, I don't think that's ideal, as it leads to duplication. The rescript package itself follows the pattern of including js build files within its npm package.

For reference, a post on the forum about this issue: https://forum.rescript-lang.org/t/how-to-publish-a-rescript-project-for-javascript-users/656/9
And the original issue as it relates to my project: quantified-uncertainty/squiggle#42

Currently, the code looks like this:

let view = (l, a) => l.get(a);
let set = (l, v, a) => l.set(v, a);
let over = (l, f, a) => {
  let v = l.get(a);
  l.set(f(v), a);
};

I'm using a redux style setup, in which I'm applying the lens over the same state over-and-over again. By making the last parameter named, you can partially apply it to not have that bit of boiler plate.

Before:

(state, action) => {
switch(action) {
| a => 
  let newState = {
    ...Lens.view(someLens, state),
    someValue
  }
  Lens.set(someLens, newState, state);
}

After:

(state, action) => {
let view = Lens.view(~state);
let set = Lens.set(~state);
switch(action) {
| a => set(someLens, {...view(someLens), someValue});
}

In my case, the implementation code looks as follows:

let make = (getter, setter) => {get: getter, set: setter};
let view = (lens, ~state) => lens.get(state);
let set = (lens, value, ~state) => lens.set(value, state);
let over = (lens, fn, ~state) => {
  let value = lens.get(state);
  lens.set(fn(value), state);
};

My only concern is that this would possibly break composability.

Hi @jonlaing :)

I don't see much activity on this repo, in the meantime I'm actively adding new features for my personal needs on a fork and I presume it would be a good thing to update the main repo as well.

look into implementing debounce and throttle ala lodash

Get some unit tests in here!