New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shift responsibility to stringify message content from Loader to runtime layer #11819
Conversation
…ime layer This (in future) will help us avoid double strigification for scenarios like chunked ops, compressed ops.
⯅ @fluid-example/bundle-size-tests: +364 Bytes
Baseline commit: dcf9599 |
| return this.submitMessage( | ||
| type, | ||
| // back-compat: ADO #1385: pass content as-is in future. | ||
| typeof contents === "string" ? contents : JSON.stringify(contents), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we do the same thing for signals? It will keep the layers consistent across our message types
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
slightly unrelated, but we also process signals in the delta manger, specifically we json parse them, and loose data, like the ref seq, which prevent us for leveraging ref seq on signals in the runtime. maybe this should be a parallel work stream to get the treatment between the two symmetrical, and ideally basically transparent to the loader layer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, but do not want to make these PRs more complex.
https://dev.azure.com/fluidframework/internal/_workitems/edit/1841
|
This commit is queued for merging with the |
| @@ -80,6 +80,9 @@ | |||
| "RemovedEnumDeclaration_BindState": { | |||
| "forwardCompat": false, | |||
| "backCompat": false | |||
| }, | |||
| "InterfaceDeclaration_IContainerContext": { | |||
| "forwardCompat": false | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vladsud - I don't think we can make any changes like this (breaking so-called forwardCompat or backCompat) for IContainerContext in main. In this case, an old implementation does not reflect the new interface. I know you add a runtime check, but this is actually causing a type compatibility problem in Bohemia codebase. I think we can work around it but just bringing to your attention.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you are right. I assumed that interface would be used only internally, but it's clearly wrong assumption.
This (in future) will help us avoid double strigification for scenarios like chunked ops, compressed ops.