Adding map functions to Node and Fragment #85

Closed
willisjtc wants to merge 3 commits from willisjtc/add-map-functions-to-node into master
willisjtc commented 2024-11-25 21:08:20 +01:00 (Migrated from github.com)

Adding map functions to be able to map over children nodes in the Node and Fragment classes.

The impetus for this is if you want to modify the child nodes in a non mutation way, you need to call forEach on a Node and push those Node's onto an array, and then make your modifications to those child nodes. The same goes for fragments.

The documentation in Fragment even states:

/// Like nodes, fragments are persistent data structures, and you
/// should not mutate them or their content. Rather, you create new
/// instances whenever needed. The API tries to make this easy.
export class Fragment {

This way, instead of using forEach we can just map over child nodes and get a new object in return. I think this also provides a cleaner way to make non-mutative changes in a syntactically cleaner style.

I didn't create an RFC just because it's a minor change.

Adding map functions to be able to map over children nodes in the Node and Fragment classes. The impetus for this is if you want to modify the child nodes in a non mutation way, you need to call `forEach` on a `Node` and push those Node's onto an array, and then make your modifications to those child nodes. The same goes for fragments. The documentation in Fragment even states: > /// Like nodes, fragments are persistent data structures, and you /// should not mutate them or their content. Rather, you create new /// instances whenever needed. The API tries to make this easy. export class Fragment { This way, instead of using `forEach` we can just map over child nodes and get a new object in return. I think this also provides a cleaner way to make non-mutative changes in a syntactically cleaner style. I didn't create an RFC just because it's a minor change.
marijnh commented 2024-11-26 11:21:14 +01:00 (Migrated from github.com)

I think that this kind of simple utility is best implemented locally in the codebase that needs it. There's a ton of possible variants (that allow deleting nodes, adding nodes, that check content rules, that automatically merge adjacent text nodes, etc) and I don't want to grow the interface on these classes too much.

I think that this kind of simple utility is best implemented locally in the codebase that needs it. There's a ton of possible variants (that allow deleting nodes, adding nodes, that check content rules, that automatically merge adjacent text nodes, etc) and I don't want to grow the interface on these classes too much.

Pull request closed

Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
prosemirror/prosemirror-model!85
No description provided.