Use continuation instead of message to signal subcomponent results #604
Conversation
Previously, `av sync` was using message passing to signal subcomponent results. By sending out a special message to the bubbletea message bus, the parent component can tell if a subcomponent finishes its process. For example, sequencerui had three messages, Conflict, Abort, and Done, to indicate its processing result. While this works, it becomes complicated to handle those messages. As we add more subcomponents, we need to handle the messages in a central message handling function. Instead of using message passing for signaling the results, use continuation passing style to handle the results. This style is already employed in the official API such as ExecProcess (https://pkg.go.dev/github.com/charmbracelet/bubbletea#ExecProcess). The benefit of the continuation passing style in `av` is that we can write the processing flow from top to bottom. The passed continuation indicates what will be done after one step. This reduces the number of messages that we need to handle in the message handler. Also, because `av` is doing processing step-by-step, it turned out that we just can forward most of the messages to the last subcomponent. This greatly simplifies the message handling code as well as the rendering code. Overall, this reduces the complexity of the implementation structure.
Current Aviator status
This PR was merged using Aviator.
See the real-time status of this PR on the
Aviator webapp.
Use the Aviator Chrome Extension
to see the status of your PR within GitHub.
|
✅ FlexReview StatusCommon Owner:
Review SLO: |
Summary of ChangesHello @draftcode, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a significant architectural refactoring to the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request is a great refactoring that simplifies the application's architecture by using continuation-passing style instead of message passing for subcomponent results. This makes the code flow more linear and easier to understand. The changes are consistently applied across all relevant components. My review includes a few suggestions to further improve maintainability by reducing some minor code duplication that was introduced.
| func (vm *postCommitRestackViewModel) Init() tea.Cmd { | ||
| state, err := vm.createState() | ||
| var err error | ||
| vm.state, err = vm.createState() | ||
| if err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| vm.restackModel = sequencerui.NewRestackModel(vm.repo, vm.db) | ||
| vm.restackModel.State = state | ||
| vm.restackModel = sequencerui.NewRestackModel(vm.repo, vm.db, vm.state, sequencerui.RestackStateOptions{ | ||
| OnConflict: func() tea.Cmd { | ||
| if err := vm.writeState(vm.state); err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| vm.quitWithConflict = true | ||
| return tea.Quit | ||
| }, | ||
| OnAbort: func() tea.Cmd { | ||
| if err := vm.writeState(nil); err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| return tea.Quit | ||
| }, | ||
| OnDone: func() tea.Cmd { | ||
| if err := vm.writeState(nil); err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| return tea.Quit | ||
| }, | ||
| }) | ||
| return vm.restackModel.Init() | ||
| } |
There was a problem hiding this comment.
The OnAbort and OnDone handlers are identical. To reduce code duplication and improve maintainability, you can define a shared function for this logic within the Init method.
func (vm *postCommitRestackViewModel) Init() tea.Cmd {
var err error
vm.state, err = vm.createState()
if err != nil {
return uiutils.ErrCmd(err)
}
onFinish := func() tea.Cmd {
if err := vm.writeState(nil); err != nil {
return uiutils.ErrCmd(err)
}
return tea.Quit
}
vm.restackModel = sequencerui.NewRestackModel(vm.repo, vm.db, vm.state, sequencerui.RestackStateOptions{
OnConflict: func() tea.Cmd {
if err := vm.writeState(vm.state); err != nil {
return uiutils.ErrCmd(err)
}
vm.quitWithConflict = true
return tea.Quit
},
OnAbort: onFinish,
OnDone: onFinish,
})
return vm.restackModel.Init()
}| func (vm *reparentViewModel) Init() tea.Cmd { | ||
| state, err := vm.createState() | ||
| var err error | ||
| vm.state, err = vm.createState() | ||
| if err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| vm.restackModel = sequencerui.NewRestackModel(vm.repo, vm.db) | ||
| vm.restackModel.State = state | ||
| vm.restackModel = sequencerui.NewRestackModel(vm.repo, vm.db, vm.state, sequencerui.RestackStateOptions{ | ||
| OnConflict: func() tea.Cmd { | ||
| if err := vm.writeState(vm.state); err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| vm.quitWithConflict = true | ||
| return tea.Quit | ||
| }, | ||
| OnAbort: func() tea.Cmd { | ||
| if err := vm.writeState(nil); err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| return tea.Quit | ||
| }, | ||
| OnDone: func() tea.Cmd { | ||
| if err := vm.writeState(nil); err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| return tea.Quit | ||
| }, | ||
| }) | ||
| return vm.restackModel.Init() | ||
| } |
There was a problem hiding this comment.
The OnAbort and OnDone handlers are identical. To reduce code duplication and improve maintainability, you can define a shared function for this logic within the Init method.
func (vm *reparentViewModel) Init() tea.Cmd {
var err error
vm.state, err = vm.createState()
if err != nil {
return uiutils.ErrCmd(err)
}
onFinish := func() tea.Cmd {
if err := vm.writeState(nil); err != nil {
return uiutils.ErrCmd(err)
}
return tea.Quit
}
vm.restackModel = sequencerui.NewRestackModel(vm.repo, vm.db, vm.state, sequencerui.RestackStateOptions{
OnConflict: func() tea.Cmd {
if err := vm.writeState(vm.state); err != nil {
return uiutils.ErrCmd(err)
}
vm.quitWithConflict = true
return tea.Quit
},
OnAbort: onFinish,
OnDone: onFinish,
})
return vm.restackModel.Init()
}| vm.restackModel = sequencerui.NewRestackModel(vm.repo, vm.db, vm.state, sequencerui.RestackStateOptions{ | ||
| Abort: restackFlags.Abort, | ||
| Continue: restackFlags.Continue, | ||
| Skip: restackFlags.Skip, | ||
| DryRun: restackFlags.DryRun, | ||
| OnConflict: func() tea.Cmd { | ||
| if err := vm.writeState(vm.state); err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| vm.quitWithConflict = true | ||
| return tea.Quit | ||
| }, | ||
| OnAbort: func() tea.Cmd { | ||
| if err := vm.writeState(nil); err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| return tea.Quit | ||
| }, | ||
| OnDone: func() tea.Cmd { | ||
| if err := vm.writeState(nil); err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| return tea.Quit | ||
| }, | ||
| }) |
There was a problem hiding this comment.
The OnAbort and OnDone handlers in the RestackStateOptions are identical. To reduce code duplication, you can define a shared function for this logic.
onFinish := func() tea.Cmd {
if err := vm.writeState(nil); err != nil {
return uiutils.ErrCmd(err)
}
return tea.Quit
}
vm.restackModel = sequencerui.NewRestackModel(vm.repo, vm.db, vm.state, sequencerui.RestackStateOptions{
Abort: restackFlags.Abort,
Continue: restackFlags.Continue,
Skip: restackFlags.Skip,
DryRun: restackFlags.DryRun,
OnConflict: func() tea.Cmd {
if err := vm.writeState(vm.state); err != nil {
return uiutils.ErrCmd(err)
}
vm.quitWithConflict = true
return tea.Quit
},
OnAbort: onFinish,
OnDone: onFinish,
})| func (vm *syncViewModel) continueWithState(state *savedSyncState) tea.Cmd { | ||
| vm.state = state.SyncState | ||
| vm.restackState = state.RestackState | ||
| return vm.addView(sequencerui.NewRestackModel(vm.repo, vm.db, state.RestackState, sequencerui.RestackStateOptions{ | ||
| Command: "av sync", | ||
| Abort: syncFlags.Abort, | ||
| Continue: syncFlags.Continue, | ||
| Skip: syncFlags.Skip, | ||
| OnConflict: func() tea.Cmd { | ||
| if err := vm.writeState(vm.restackState); err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| vm.quitWithConflict = true | ||
| return tea.Quit | ||
| }, | ||
| OnAbort: func() tea.Cmd { | ||
| if err := vm.writeState(nil); err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| return tea.Quit | ||
| }, | ||
| OnDone: func() tea.Cmd { | ||
| if err := vm.writeState(nil); err != nil { | ||
| return uiutils.ErrCmd(err) | ||
| } | ||
| return vm.initPushBranches() | ||
| }, | ||
| })) | ||
| } |
There was a problem hiding this comment.
The OnAbort and OnDone handlers share common logic for clearing the state. You can extract this into a helper function within continueWithState to reduce duplication and make the intent clearer.
func (vm *syncViewModel) continueWithState(state *savedSyncState) tea.Cmd {
vm.state = state.SyncState
vm.restackState = state.RestackState
clearStateAndContinue := func(next tea.Cmd) tea.Cmd {
if err := vm.writeState(nil); err != nil {
return uiutils.ErrCmd(err)
}
return next
}
return vm.addView(sequencerui.NewRestackModel(vm.repo, vm.db, state.RestackState, sequencerui.RestackStateOptions{
Command: "av sync",
Abort: syncFlags.Abort,
Continue: syncFlags.Continue,
Skip: syncFlags.Skip,
OnConflict: func() tea.Cmd {
if err := vm.writeState(vm.restackState); err != nil {
return uiutils.ErrCmd(err)
}
vm.quitWithConflict = true
return tea.Quit
},
OnAbort: func() tea.Cmd {
return clearStateAndContinue(tea.Quit)
},
OnDone: func() tea.Cmd {
return clearStateAndContinue(vm.initPushBranches())
},
}))
}
Previously,
av syncwas using message passing to signal subcomponentresults. By sending out a special message to the bubbletea message bus,
the parent component can tell if a subcomponent finishes its process.
For example, sequencerui had three messages, Conflict, Abort, and Done,
to indicate its processing result.
While this works, it becomes complicated to handle those messages. As we
add more subcomponents, we need to handle the messages in a central
message handling function.
Instead of using message passing for signaling the results, use
continuation passing style to handle the results. This style is already
employed in the official API such as ExecProcess
(https://pkg.go.dev/github.com/charmbracelet/bubbletea#ExecProcess).
The benefit of the continuation passing style in
avis that we canwrite the processing flow from top to bottom. The passed continuation
indicates what will be done after one step. This reduces the number of
messages that we need to handle in the message handler.
Also, because
avis doing processing step-by-step, it turned out thatwe just can forward most of the messages to the last subcomponent. This
greatly simplifies the message handling code as well as the rendering
code.
Overall, this reduces the complexity of the implementation structure.