-
-
Notifications
You must be signed in to change notification settings - Fork 122
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
RichTextAction subscription #129
Conversation
@danielsaidi Can you please take a look when you have some free time to ensure we are going correct direction? This is breaking change, changing published properties to internal for them to reflect only and only be used with binding(for)... |
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.
Great job! I have some comments that we need to fix though :)
Sources/RichTextKit/Coordinator/RichTextCoordinator+ColorSubscriptions.swift
Outdated
Show resolved
Hide resolved
b4ccd3b
to
b4bd81d
Compare
7c76788
to
076651f
Compare
case .setUnderlineColor: .underlineColor | ||
case .setStrikethroughColor: .strikethroughColor | ||
case .setStrokeColor: .strokeColor | ||
case .setColor(_, let richTextColor): |
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.
@DominikBucher12 I thiiiiink the rich text color has a title that you can return right away.
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 actually does not :( I wouldn't implement it in there IMHO, but the icons can stay.
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'll fix! :)
case .strikethrough: .strikethroughColor | ||
case .stroke: .strokeColor | ||
case .underline: .underlineColor | ||
case .undefined: .strokeColor |
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.
Is this correct for the undefined?
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.
You need to return something and this feels a lot better than exception or cascade of optionals. I would personally focus after 1.0 to get away from undefined
...
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 love this so much!
|
||
/// Whether or not the latest undone change can be redone. | ||
@Published | ||
public var canRedoLatestChange = false | ||
var canRedoLatestChange = false |
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.
But actually, removing public
from these are breaking changes. I think we can do it if we don't release this PR as a 0.9 patch, but as a 1.0 bump.
I also don't understand how other parts of an app would be able to refresh if they can't listen to these published properties?? 🤔
What this PR do:
userActionPublisher
!How to test it
TODO