[IN PROGRESS] refactor: Refactor scrollable table widgets #265
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
A description of the change and what it does. If relevant, please provide screenshots of what results from the change:
The goal of this refactor is to help reduce some duplicated code, and make it easier to add new widgets as required. To start, this will mostly be targeting scrollable table widgets, since they're some of the more complicated widgets in terms of state management and user interaction.
The main idea behind this change is to move on from the current system of each widget having three separated parts:
app.rs
)The biggest issue was that adding a new widget was painful to say the least - you would have to create a new state manager, write new code to handle events, and then write drawing code! To address this, I was planning on refactoring this AFTER 0.5.0 released, but given how much trouble this was giving me during the config implementation planning, I decided to do some of this now.
The new concept planned (and implemented for scrollable tables for now) is:
Introduce "components" that represent base parts of a widget. So for things like processes, disks, etc., these are all scrollable tables. As such, the
ScrollableTable
trait would represent the base methods we want all scrollable tables to have. This means I don't have to have 5 different implementations of how to increment the table scroll cursor.Unify widget state management and drawing together. Since we already keep track of all these widget states within the overarching app state, we can just simply call the widget's drawing function.
Type of change
Remove the irrelevant ones:
Test methodology
If relevant, please state how this was tested:
Furthermore, please tick which platforms this change was tested on:
If relevant, all of these platforms should be tested.
Checklist
If relevant, ensure the following have been met:
cargo test
check)cargo fmt
)