OT Integration - Part 2 #305
Conversation
| } | ||
|
|
||
| const normalizeCustomTextPath = (contentBlock: CustomText, op: NodeOperation | TextOperation): number[] => { | ||
| // TODO: For Mae :P - So the issue here is that fields on javascript objects are unordered, this is unlike Go where (typically) the order in which |
There was a problem hiding this comment.
actual unironic comment: this isn't quite correct, objects do maintain some order:
The traversal order, as of modern ECMAScript specification, is well-defined and consistent across implementations. Within each component of the prototype chain, all non-negative integer keys (those that can be array indices) will be traversed first in ascending order by value, then other string keys in ascending chronological order of property creation.
(MDN for..in, this also extends to object methods like Object.keys() and Object.entries())
There was a problem hiding this comment.
Oh thats convenient, so should it directly correspond to the the order declared in the TS type? IE in this example:
type field = {
a: string
b: string
aca: string
}
const x = { b: "hello", a: "world", aca: "there" };
const y = { a: "hello", b: "world", aca: "there" };would x and y produce the same order for keys?
There was a problem hiding this comment.
Oh thats convenient, so should it directly correspond to the the order declared in the TS type?
Wait ig not since it depends on order of declaration in the prototype so ig anyone can declare it in any order they want
There was a problem hiding this comment.
not necessarily as declared in the type, as those aren't available at runtime - if you do something like send an json object from the backend and parse that from the frontend, it should maintain whatever order it was sent in (assuming there's no integer keys)
There was a problem hiding this comment.
Hmm issue is though is that slate doesn't actually seem to give us a guarantee on order (for starters since it doesn't surface the entire object that its updated and only surfaces the field) because at the very least in Go I can just use reflection to map fields to their declaration order which doesn't seem possible at all in JS given each instance of a type could have a different field order
Co-authored-by: Michael Vo <[email protected]>
No description provided.