-
Notifications
You must be signed in to change notification settings - Fork 280
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
Feature/react #946
Feature/react #946
Conversation
Fix #845 - Remove resizer everytime the cursor gets out of the pillar. Keeping the resizer there without any reason creates a black hole where the CKEditor's mousemove event is never triggered
Fix autolink test
Fix #898 | Added center align css interaction between IE11 and other …
LPS-87500 Add styleFn support for the ButtonStylesList component
Fixes #911 Use correct CSS to place drag resize handle at the corner
Fixes #900 Add closing …
Fixes #915 - Checks if selection data exists in linkSelectionTest
…de the style attribute so as to be consistent with the standard AlloyEditor resizing behavior.
Change dragresize implementation on IE to modify heigh and width insi…
Fixes #928 | Update gulp-sass to work with node v10.x.x
Fixes #931 | Fixes the saucelabs browser-matrix badge
Hey @bryceosterhaus and @matuzalemsteles, This is an attempt to update react to the latest version (at this time If you have a moment could you please take a look. There are still things to be done, for example:
But I think that the most important thing is checking that everything works fine (which I did but I think a second look will be more than welcome) so that we can continue "pushing alloy-editor forward" Thanks for your help and time! |
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.
Hey @julien,
I noticed a few things, nothing major but just wanted to get your thoughts on it.
I also noticed a bunch of whitespace changes, I assume this is just because we don't have a lint or format task? Also, any idea why we have a range of file extensions? I noticed we had .js
for both es5 and es6 code and then also had some .jsx
files mixed in there too.
Other than those few things, it looks good so far, glad to see we are updating it.
Also, I only looked at the update commit, should've I looked at the whole PR?
src/components/base/button-style.js
Outdated
}; | ||
|
||
// WrappedComponent.propTypes = { |
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 block supposed to be commented out?
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.
Well, no ... but I doesn't seem to be needed either.
I'll remove it and clean that.
@@ -45,10 +72,10 @@ export default WrappedComponent => class extends WrappedComponent { | |||
return button; | |||
}) | |||
) | |||
.map(function(button) { | |||
.map(function(button, index) { | |||
var props = this.mergeExclusiveProps({ | |||
editor: this.props.editor, |
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
working properly here? I would expect it to be referring to the function(button, index)
closure.
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.
Yes it is
* @return {Array} An Array which contains the buttons or button groups that should be rendered. | ||
*/ | ||
getToolbarButtonGroups(buttons, additionalProps) { | ||
var instance = 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 don't remember what our pattern for this is in portal, but it seems weird to be setting var instance = this;
for a react component. Will we ever be using instance
and this
where they reference to two different things?
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 agree that it seems weird in a React.Component
but for the moment I'm just copying the existing code over ...
A possible improvement could simply be using an arrow function
return buttons.reduce((list, button) => {
if (Array.isArray(button)) {
list.push(this.getToolbarButtons(button, additionalProps));
return list;
} else {
return this.getToolbarButtons(buttons, additionalProps);
}
}, []);
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.
Oh gotcha, I wasn't aware it was just copied over. Should be fine as is, we can update and refactor later.
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.
Ok great.
var buttonCommandsListId; | ||
|
||
if (this.props.expanded) { | ||
buttonCommandsListId = ButtonParagraphAlign.key + 'List'; |
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.
whitespace looks a bit too large here. Maybe its just GH's rendering of it though.
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.
Yes, that's actually because the project has "mixed spaces and tabs" ...
I'll reformat it for now.
In this project the .eslintrc
file specifices we should be using 4 spaces for indentation.
We might want to change that later when we add a format
/lint
task and use tabs like in other projects?
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.
Yeah using tabs is probably best. At least to just be consistent across projects.
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 I'll add that when I work on #926
* | ||
* @class ButtonSeparator | ||
*/ | ||
class ButtonSeparator extends React.Component { |
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.
Would it make sense to use a function component here since there is no internal state?
I'm not positive about the implications of it with the latest react version, but I remember there being performance implications in the past. Using function components were preferred over class components if there was no state.
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.
Ok, I'll check that out, sounds like a good 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.
@bryceosterhaus Ok so I changed this to a function component, but it still makes has a static key
property, tell me if that is an issue.
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.
That should be fine!
currentSelection.buttons, | ||
var buttons = currentSelection.buttons; | ||
|
||
if (typeof buttons === 'object' && !Array.isArray(buttons)) { |
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.
Do we have any helpers available that we could use for these sorts of things? idk if we want to include metal-core for some of those things.
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.
Personally, I don't really know either.
It might be an improvement for later, but for the moment I don't think it's much of a problem having this like it is now.
buttonsGroup.map(function (value, index) { | ||
if (Array.isArray(value)) { | ||
return ( | ||
<div className="ae-row" key={index.toString()}> |
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 the toString()
is necessary here? Seems like you could just pass the index to key and it would be fine.
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're right, it's not needed
<div className="ae-row" key={index.toString()}> | ||
{ | ||
value.map(function (button) { | ||
return button; |
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 might also want to add a key
here somehow for safe keeping.
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 mean in the button?
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 actually might be fine since you aren't returning a jsx element. Usually react will complain about not having a key
attr on lists. https://reactjs.org/docs/lists-and-keys.html
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.
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.
As long as there are no client-side errors for the "key", it should be good! React is usually pretty good at emitting warnings to the console for things like this.
Hey @bryceosterhaus, Thanks for the review, yes the idea was to review the last commit. |
@julien Other than the few changes you noted in making, it looks good to me. Any code that you copied over, I wouldn't worry about changing or refactoring unless its needed by the version change. |
Updated changes look good to me! |
@bryceosterhaus thanks again for the review! |
Please employ to following template as the base structure of Pull Requests for AlloyEditor (liferay/alloy-editor) project. Pull Requests not incorporating the sections below will be regarded as unsatisfying and rejected.
Prelude
Preliminary history of the issue related to this very Pull Request. Share any information that could ease the understanding of why this issue exists and what measures have been administered to address it.
Issue
Link the issue from the issues list with any complementary explanation that is required to have a solid understanding of it.
Solution
Line up the major changes that have been applied.
Test
Append a comprehensive list of devices against which the implementation was tested. This is relevant only if the issue described incorporates various behaviours on different devices.
If possible attach an animated GIF of the major scenarios that have been affected by the change, so that non-techincal participants can also have a better undertanding of the subject matter.