That's something I landed on after a fair bit of analysis elaborated upon within the Correction-Search + Context-Tracking design doc.
While originally, the id field on a Transform was just that - an id associated with a specific keystroke and its transform... it's kind of come to mean more than that. From my analysis, it also acts as an id on the context-state from before the transition. We already use the transform ID of a suggestion to retrieve its original context-state when doing reversions, and that of the base tap's keystroke to retrieve the original context-state when doing multitaps. For both, we need the base context-state, and for the former, we also need the original Transform to properly replicate the original effects. In essence... it identifies both aspects of the context transition - and recognizing and modeling the transition as its own entity (ContextTransition) seems the best acknowledgment. Saying it's just the ID of the transform feels less clear to me.
There probably needs to be, when all is said and done, at least a round of doc-comment work about all the implications and associations the once-humble transform ID has within the web engine and predictive-text engine. It applies to more than just transforms now. Heck, it has applied to more for a while... I'm just realizing it much more explicitly thanks to all the design / analysis efforts I've recently been putting in for epic/autocorrect.
Originally posted by @jahorton in #14440 (comment)
That's something I landed on after a fair bit of analysis elaborated upon within the Correction-Search + Context-Tracking design doc.
While originally, the
idfield on aTransformwas just that - an id associated with a specific keystroke and its transform... it's kind of come to mean more than that. From my analysis, it also acts as an id on the context-state from before the transition. We already use the transform ID of a suggestion to retrieve its original context-state when doing reversions, and that of the base tap's keystroke to retrieve the original context-state when doing multitaps. For both, we need the base context-state, and for the former, we also need the original Transform to properly replicate the original effects. In essence... it identifies both aspects of the context transition - and recognizing and modeling the transition as its own entity (ContextTransition) seems the best acknowledgment. Saying it's just the ID of the transform feels less clear to me.There probably needs to be, when all is said and done, at least a round of doc-comment work about all the implications and associations the once-humble transform ID has within the web engine and predictive-text engine. It applies to more than just transforms now. Heck, it has applied to more for a while... I'm just realizing it much more explicitly thanks to all the design / analysis efforts I've recently been putting in for epic/autocorrect.
Originally posted by @jahorton in #14440 (comment)