Skip to content
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

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

CatHood0
Copy link
Collaborator

@CatHood0 CatHood0 commented Sep 23, 2024

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 and romanNumbers from text_block file because they were no longer used internally and were just taking up unnecessary space.

  • New feature: Adds new functionality without breaking existing features.
  • 🛠️ Bug fix: Resolves an issue without altering current behavior.
  • 🧹 Code refactor: Code restructuring that does not affect behavior.
  • Breaking change: Alters existing functionality and requires updates.
  • 🧪 Tests: Adds new tests or modifies existing tests.
  • 📝 Documentation: Updates or additions to documentation.
  • 🗑️ Chore: Routine tasks, or maintenance.
  • Build configuration change: Changes to build or deploy processes.

TODO:

  • we need to test if these changes don't break nothing.
  • we need to add some documentation easy to understand for the new files.

@CatHood0 CatHood0 added documentation Improvements or additions to documentation in progress This issue or feature is currently being worked on by someone. labels Sep 23, 2024
@CatHood0 CatHood0 self-assigned this Sep 23, 2024
@CatHood0 CatHood0 requested a review from EchoEllet September 23, 2024 19:04
@CatHood0 CatHood0 marked this pull request as draft September 23, 2024 19:04
@EchoEllet
Copy link
Collaborator

Will review it soon. It's usually more effective to review those changes in the IDE or command line instead of GitHub Web.

Copy link
Collaborator

@EchoEllet EchoEllet left a 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.

Copy link
Collaborator

@AtlasAutocode AtlasAutocode left a 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

@EchoEllet
Copy link
Collaborator

EchoEllet commented Sep 23, 2024

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 @internal in it to ensure that user can't accidentally use an internal API. I do get reports about breaking changes when it's not clear that this is an internal API or accidentally made out to the public by a PR.

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 @internal when we can and that's something to address.


@override
TextPosition? getPositionAbove(TextPosition position) {
assert(position.offset < container.length);
Copy link
Collaborator

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);
Copy link
Collaborator

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.

Comment on lines +1 to +20
import 'package:flutter/material.dart'
show
Border,
BorderSide,
BoxDecoration,
BuildContext,
Color,
Colors,
Directionality,
EdgeInsets,
FontWeight,
MediaQuery,
StatelessWidget,
TextDirection,
TextRange,
TextSelection,
ValueChanged,
Widget,
debugCheckHasMediaQuery,
immutable;
Copy link
Collaborator

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

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')

Copy link
Collaborator Author

@CatHood0 CatHood0 Sep 24, 2024

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.

Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

@EchoEllet EchoEllet Sep 24, 2024

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.

Comment on lines +37 to +40
assert(_slotToChildren.containsValue(child));
assert(child.slot is TextLineSlot);
assert(_slotToChildren.containsKey(child.slot));
_slotToChildren.remove(child.slot);
Copy link
Collaborator

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);
Copy link
Collaborator

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);
Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Collaborator

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(
Copy link
Collaborator

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.

Copy link
Collaborator

@EchoEllet EchoEllet left a 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.

@CatHood0
Copy link
Collaborator Author

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.

@EchoEllet
Copy link
Collaborator

@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 master after the updates (insufficient permission).

@CatHood0
Copy link
Collaborator Author

@EchoEllet there's no problem for you to make a new PR if necessary. Thank you very much for taking the time.

@EchoEllet
Copy link
Collaborator

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.

@CatHood0
Copy link
Collaborator Author

CatHood0 commented Nov 14, 2024

Can you push your branch to this repo instead so we can both make changes?

It's ready now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation in progress This issue or feature is currently being worked on by someone.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants