bubbletea: adds bubbletea table component and prepares Update method for supporting multi models.

[chris-ramon]

Details

• bubbletea: syncs unit tests.
• bubbletea: syncs ChoicesModel.Update method.
• bubbletea: adds Model updates and improves Bubbletea.Update method.
• bubbletea: syncs unit tests.
• bubbletea: removes unused ChoicesModel.table field.
• bubbletea: handles current model update method upstream.
• bubbletea/tablemodel: adds bubbletea table.

Test Plan

• ✔️ Tested that the CLI works as expected via ./bin/dev.sh:

(base) chris@chris:~/Projects/graphql-compatibility/compatibility-base$ ./bin/dev.sh 
┌────────────────────────────────────────────────────────────────────────────────┐
│                                                                                │
│ Reference Implementation: https://github.com/graphql/graphql-                  │
│ js/releases/tag/v0.6.0                                                         │
│ (•) Implementation: https://github.com/graphql-go/graphql/releases/tag/v0.8.1  │
│                                                                                │
│                                                                                │
│ (press q to quit)                                                              │
│                                                                                │
└────────────────────────────────────────────────────────────────────────────────┘
2025/05/19 13:09:16 &{}

• ✔️ Tested that the CLI works as expected via ./bin/test.sh:

(base) chris@chris:~/Projects/graphql-compatibility/compatibility-base$ ./bin/test.sh 
?   	github.com/graphql-go/compatibility-base	[no test files]
?   	github.com/graphql-go/compatibility-base/assert	[no test files]
ok  	github.com/graphql-go/compatibility-base/bubbletea	0.005s
?   	github.com/graphql-go/compatibility-base/cmd	[no test files]
ok  	github.com/graphql-go/compatibility-base/config	0.002s
?   	github.com/graphql-go/compatibility-base/implementation	[no test files]
ok  	github.com/graphql-go/compatibility-base/puller	0.003s
?   	github.com/graphql-go/compatibility-base/types	[no test files]

[mentatbot]

I'm getting to work. See my steps and track my cost here.

• Wake on any new activity.
  _{I always see new activity while actively working. When paused, I'll only respond when tagged unless this box is checked.}

[mentatbot]

Thanks for working on this PR! I've reviewed the changes to implement the bubbletea table component.

The changes look good - you've properly implemented the NewTableModel function following the existing patterns in the codebase, initializing the table with appropriate configuration options.

A few observations:

• The reordering of struct fields makes sense for consistency
• The initialization of the table in NewTableModel follows patterns similar to other models
• I see the TODO comment about wiring the TableModel component - is this PR intended to be a partial implementation that will be completed in future PRs?

Overall, the implementation is clean and follows the established patterns in the codebase. There are no tests specifically for the TableModel implementation, but this is consistent with how other models are handled in the codebase.

[chris-ramon]

@MentatBot could you give a second review about the last batch of commits send ?

[mentatbot]

Thanks for the additional changes to the PR! I've reviewed the latest commits and I'm impressed with the architectural improvements you've made.

The changes go beyond just adding the TableModel implementation to significantly improve the bubbletea component architecture:

Architecture Improvements:

1. Enhanced Model Interface: You've formalized the Model interface with proper documentation and improved method signatures.
2. Better State Management:
   • Changed Update() to use pointer receivers for models
   • The BubbleTea component now properly preserves model state updates
3. Code Cleanup: Removed unused fields like the table field in ChoicesModel

TableModel Implementation:

• The implementation is clean and follows the pattern established for other models
• Properly initializes the table with the necessary configuration

Test Updates:

• Tests have been appropriately updated to match the new architectural changes
• Test assertions now accurately reflect the expected model state after updates

All of these changes work together to create a more robust architecture that handles state management properly. The pointer receiver pattern for Update() methods is especially important for maintaining state across updates.

The tests are passing and the CLI is working as shown in your test results. This is a significant improvement to the codebase, and the TableModel implementation is structured well to allow for future expansion.

[mentatbot]

The TableModel.Update method should use a pointer receiver and return (Model, tea.Cmd) to match the Model interface signature and ensure state is properly maintained (like the changes made to ChoicesModel.Update).

Suggested change

	// `Init` is the `TableModel` method required for implementing the `Model` interface.
	func (tm *TableModel) Update(msg tea.Msg) (Model, tea.Cmd) { //nolint:golint,ireturn

[chris-ramon]

@MentatBot nice catch ! - since currently we are not using TableModel I'll go ahead and update it in a follow-up PR, I've created an issue for addressing this: #19.

[mentatbot]

That sounds like a reasonable approach! Thanks for creating an issue to track this. Addressing it in a follow-up PR makes sense, especially since the TableModel isn't currently in active use. The current PR already makes significant architectural improvements to the codebase.

[mentatbot]

For consistency with the other methods in TableModel and to ensure proper state management, it would be good to use a pointer receiver for the Run method as well.

Suggested change

	func (tm *TableModel) Run(model any) (any, error) {

[chris-ramon]

@MentatBot nice suggestion - I've added this to the follow-up PR issue: #19, I'll consider addressing this.

[mentatbot]

Thanks for adding this to the follow-up issue as well. Both suggestions relate to the same architectural pattern of using pointer receivers consistently, so addressing them together makes sense. Since the TableModel isn't actively used yet, this approach maintains good code organization while planning for future improvements.

[chris-ramon]

LGTM 👍 🚢

[mentatbot]

Agreed! These changes look good to merge. The architecture improvements are solid, and the follow-up issues will handle the minor adjustments we discussed. Nice work on this PR!