-
Notifications
You must be signed in to change notification settings - Fork 845
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
Chore: move editor text elements into separate files when possible #2274
base: master
Are you sure you want to change the base?
Conversation
Will review it soon. It's usually more effective to review those changes in the IDE or command line instead of GitHub Web. |
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.
Haven't reviewed the PR yet.
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.
Looks OK to me
Still need a bit more time before working on #2251 or fully reviewing this change. We need some tests to ensure that we're not exposing any file that have Added a breaking changes section to explain this in #2275 though still not quite enough. Should require minimal effort to fix. The issue that we're not using |
|
||
@override | ||
TextPosition? getPositionAbove(TextPosition position) { | ||
assert(position.offset < container.length); |
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.
We need to add a message for all asserts, even if we're not sure about the check and why it's done, a message or something like:
Position offset ($position.offset) must be less than the container length (${container.length}).
|
||
@override | ||
TextPosition? getPositionBelow(TextPosition position) { | ||
assert(position.offset < container.length); |
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.
This seems to be the same assert check as the one in getPositionAbove
. Also need a message.
import 'package:flutter/material.dart' | ||
show | ||
Border, | ||
BorderSide, | ||
BoxDecoration, | ||
BuildContext, | ||
Color, | ||
Colors, | ||
Directionality, | ||
EdgeInsets, | ||
FontWeight, | ||
MediaQuery, | ||
StatelessWidget, | ||
TextDirection, | ||
TextRange, | ||
TextSelection, | ||
ValueChanged, | ||
Widget, | ||
debugCheckHasMediaQuery, | ||
immutable; |
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.
Let's remove the show
here and only use it when we it for other reasons such as this line since I accidentally used exitProcess
instead of the exitCode
of the xclip
process.
import '../../../../document/nodes/block.dart'; | ||
import 'render_editable_text_block.dart'; | ||
|
||
//TODO: we need to document what does this and why we use it |
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.
@AtlasAutocode @singerdmx Any idea?
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.
It looks like this was being used to separate the widget logic from the build and rendering logic.
For a StatefulWidget, we would use WidgetState to achieve the same purpose.
I guess I would leave it as a private class only callable from its parent EditableTextBlock. If we extract it as a separate public class, it could be mis-called from who knows where. (And people will ask 'why do we use this')
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 will add some documentation about what makes this class. We have some docs about this, but i have no much time. I will search and add it correctly as soon as possible.
I wrote that TODO to remember that i need to add it.
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.
Take as much time as you need.
import 'render_editable_text_line.dart'; | ||
import 'render_text_line_element.dart'; | ||
|
||
//TODO: we need to document this render object |
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.
@singerdmx Same question
@@ -0,0 +1,114 @@ | |||
import 'package:flutter/material.dart' | |||
show |
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.
Same as before, once we start importing more classes and properties, it will become bigger and a bit harder to review. Also, requires changes when we remove something.
assert(_slotToChildren.containsValue(child)); | ||
assert(child.slot is TextLineSlot); | ||
assert(_slotToChildren.containsKey(child.slot)); | ||
_slotToChildren.remove(child.slot); |
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.
Those do need messages as well.
@override | ||
void update(EditableTextLine newWidget) { | ||
super.update(newWidget); | ||
assert(widget == newWidget); |
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.
Same to all the other asserts, we can make it in a separate PR if you prefer.
|
||
@override | ||
void insertRenderObjectChild(RenderBox child, TextLineSlot? slot) { | ||
// assert(child is RenderBox); |
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.
Why this was commented? We should check the history and see if it was commented by a PR that introduced a feature or some other changes. If there is a reason, then it should be removed.
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 have found that some issues are reported as causing an assert failure.
A contributor then comments out the assert without searching for why the assert failed.
In my experience, asserts are indicators of a logic error that occurred prior to the assertion.
It is imperative to find the originating cause rather than just ignoring the problem which inevitably results in a future serious failure that is hard to fix. But this is a maintainability issue that most people are not sensitive to since they have not had to maintain a project for years.
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 found a similar issue in the magnifier PR, but I didn't have a chance to revert it, though I will soon.
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.
To make it easier for future developers and to keep track of code quality best practices, we need general guidelines and common code quality standards that must be followed consistently throughout the project. A file somewhere in the doc
directory or in CONTRIBUTING.md
.
} | ||
|
||
@override | ||
void moveRenderObjectChild( |
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.
We need to know why this is not implemented and is not needed, same as the other methods that need to be implemented but always throw something like UnimplementedError
or similar.
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.
Thank you for the cleanup.
I apologize for the inactivity I have had. In one or two days I will start again, resume activity and continue with the PRs that I have active. Anyway I have to take some time to remember what I was doing in this PR. |
@CatHood0 Do you want me to handle those conflicts? If yes, then I need to push changes to your fork or create a new PR since I'm unable to push directly or merge with |
@EchoEllet there's no problem for you to make a new PR if necessary. Thank you very much for taking the time. |
Can you push your branch to this repo instead so we can both make changes? Since I only plan to make minor changes, including fixing conflicts. |
It's ready now. |
Description
The decision was made to separate the text element widgets into their own separate files in order to not only separate the logic, but to make it more readable and easy to debug.
This decision was made since there are many files with this pattern, of having a lot of internal logic that is not completely related in the same place, being that we could separate them into different files.
If this PR is merged, we will likely continue to do this type of refactoring since it improves readability and makes it easier to implement solutions since we do not have to read a 1600 line file.
arabianRomanNumbers
andromanNumbers
fromtext_block
file because they were no longer used internally and were just taking up unnecessary space.TODO: