Changing doc.attrs?

23

I’m relatively new to using prosemirror so I may be mistaken but I thought the document was supposed to be immutable. Wouldn’t this manipulate the current doc instance since it’s not creating a new doc?

24

@andrews - yes, the solutions in this thread modify the document in place. Whether that is a problem depends on what else you are doing in the transaction that uses this step (and how your application consumes transactions). We didn’t see any specific issues with this in the original situations we used this approach in, but have since switched to apply functions that produce a new document to support some additional use cases, e.g.:

apply(doc) { 
  const newDoc = Node.fromJSON(schema, doc.toJSON());

  newDoc.attrs.someData = produceNewSomeData(doc.attrs.someData);

  return StepResult.ok(newDoc);
}
1 Like
25

Thanks. Yes that makes sense - would probably just need to alter the example to use the newDoc in the result. :slight_smile:

1 Like
26

@marijn I saw you mentioned back in '18 this might be a good thing to add to prosemirror-transform. I would like to add this to ProseMirror.Net and, if it’s still a good idea, prosemirror-transform. Would you take a PR? If so what would it look like? -1 or some other option to address doc? A separate step completely?

Thanks!

27

It would have to be a separate step. And yeah, I’d be okay to review a PR for this.

28

Awesome! I’ll get that together.

I’d also like to propose an option to relax attr key restrictions… Currently only attrs with keys defined in the spec will assigned at node creation due to computeAttrs; extra keys are silently ignored.

If there were a spec option to allow undefined keys, or perhaps keys matching some pattern, then arbitrary metadata could be stored in attrs with key-level conflicts without having to use the metadata node pattern…

I could open an RFC for this… Doesn’t look like that repo sees much action.

Edit: To expand on “key-level conflicts” I mean that because we have key-level update granularity we can update dynamic keyed metadata with last-writer-wins(or a custom conflict resolution strategy via transaction interceptors) semantics per-key. Vs at the object level, or having to resort to a metadata node.

29

I don’t think I want to change this. A custom step similar to AttrStep could make updates to properties of some generic ‘meta’ attribute less conflicty, maybe.

30

Fair. Yeah, I can make a custom step that operates over an attrs object instead of attrs itself.

31

Any chance you could share what you’re working on? I’m looking for a way to update document level attributes in TipTap.

32

Read the docs at ProseMirror Reference manual

33

I’m just storing data structures referenced by data structures in nodes, but that are not themselves related to any particular node.

I also plan to store some extra meta information about the document in the doc node; schema version, features enabled, and etc.

Per the prior comment I have already contributed this as DocAttrStep in the referenced documentation.