Add recursive conversion routines?

[littledan]

Various people have raised the feature request that a recursive conversion routine should be built-in, to convert structures of Objects and Arrays to Records and Tuples. Lots of JS immutable data structure libraries have this capability.

The current draft proposal does not contain recursive conversion routines, though of course they can be implemented in JS. I think these are often used inappropriately (e.g., to clone, which should be unnecessary), and I'm not convinced we should encourage this pattern with a built-in function.

I'd be open to adding this, if we have good use cases. One option is that we could make a depth limit parameter, as the README suggests. I'm not sure if this would result in feeling too low-level, though (and people could always get around it by using a large value...).

cc @rauschma

[pabloalmunia]

Usually, the Javascript language only provide functions to superficial transformation, for example, Object.assign() only work into the first level and don't work recursively into next object levels.

A good recursive function should be to work with circular references and other complex situations. JSON.stringify () is the only function that works in depth and has serious problems with circular reference situations.

In my experience (I've developed a recursive immutability library https://www.todojs.com/datos-inmutables-en-javascript/ ) it's more idiomatic that maintained built-in functions are kept at the superficial level.

[papb]

I think this could be left to another proposal, if necessary. It might be safer to have this proposal land without this feature first, and then see how it goes, maybe?

[njordhov]

I'd be open to adding this, if we have good use cases.

The syntax for record literals can be simpler without confusion if the Record constructor recursively converts objects to records. It introduces a mental model where it is consistent to use object literal syntax within a record literal, instead of having to use the "you must specify the # at every level" record syntax for child props:

const record = #{
  a: { foo: "string" },
  b: { bar: 123 }
};

With recursive conversion of nested objects being the expectation, record literals would be consistent without the # at every level, resolving the concern of apparent object literals behaving differently within a record literal than outside:

const rec = #{ a: {} }; // this works

const a = {};
const rec = #{ a: a }; // this no longer throws a type error.

Also, the spread operator will be more consistent and symmetrical. Per the proposal, a spread" will create an object, not a record. With conversion of objects in record literals, the object from the destructuring spread can be used directly in a record literal without explicit conversion:

const { a, ...rest } = #{ a: 1, b: 2, c: 3 };
const back_again = #{ a, ...rest } ;

[littledan]

@njordhov I've hidden your comment since this issue is about recursive conversion routines, not syntax. You've already been arguing for this syntax change on #10; no need to spread that conversation out over multiple issues.

[njordhov]

@njordhov I've hidden your comment since this issue is about recursive conversion routines, not syntax. You've already been arguing for this syntax change on #10; no need to spread that conversation out over multiple issues.

The point is that having recursive conversion routines makes a cleaner record literal syntax comprehensible rather than confusing. This is an on-topic response to the request in OP, making a case in favor of adding recursive conversion. The original post is here, with only a brief mention added to #10 (before I had to answer to what seems like knee-jerk responses from the past syntax discussion).

[rricard]

In order to focus on changes that are necessary to finish this proposal, we are closing issues related to follow-on proposals. You are free to continue the discussion here and reference it in other venues.