Type definition for evolve breaks nested evolution. about npm-ramda HOT 13 CLOSED

Can you check if the definition works for you?

from npm-ramda.

@donnut yes that is the definition we had prior to updating the definition which worked fine for nested evolutions.

from npm-ramda.

I created an alternative typing. Can you check if this works for you? And maybe share the snipped you encountered problems with?

from npm-ramda.

@brianbondlink do you have a snippet to share 😉

from npm-ramda.

Sorry @donnut missed your last reply. I haven't gotten to test the typing yet, but for a snippet take a look at the ramda docs for evolve. It demonstrates the nested evolution that was broken initially

from npm-ramda.

Ok, thanks. The ramda doc example is fixed with this modification.

from npm-ramda.

Excellent thank you

from npm-ramda.

I'll update the code this weekend. Thanks for reporting the issue 👍

from npm-ramda.

@brianbondlink
done in bc6c44a

from npm-ramda.

Thanks!

from npm-ramda.

The test of evolve fails after all (not in the atom-editor?). Has to do with [index: string] key.

from npm-ramda.

I am also having problems with the definition currently on master.
To me this:

     interface xpto  { a: number, b: number };
     var test : xpto = { a: 1, b: 2};
     const a3 : xpto = R.evolve({ a: R.add(1)}, test );

Is totally valid code, that typescript rejects with:

TS2322: Type 'Nested<xpto>' is not assignable to type 'xpto'.Property 'a' is missing in type 'Nested<xpto>'. [typescript/tsc]

With the alternative it works:

evolve(transformations: {[index: string]: (value: any) => any}, obj: any): any;
evolve(transformations: {[index: string]: (value: any) => any}): (obj: any) => any;

from npm-ramda.

Right now, both versions of the typing are in, meaning all tests are passing. However, that doesn't mean this is resolved yet; our currently having to resort to any typings here shows that there is room for improvement in our inference.

from npm-ramda.