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

Feature/react #946

Merged
merged 330 commits into from
Dec 26, 2018
Merged

Feature/react #946

merged 330 commits into from
Dec 26, 2018

Conversation

julien
Copy link
Contributor

@julien julien commented Dec 19, 2018

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.

julien and others added 30 commits October 23, 2018 10:01
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 #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 #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
@julien
Copy link
Contributor Author

julien commented Dec 19, 2018

Hey @bryceosterhaus and @matuzalemsteles,

This is an attempt to update react to the latest version (at this time v16.6.3) and apply various fixes we made.

If you have a moment could you please take a look.

There are still things to be done, for example:

  • Some files are still written in ES5 (inside a IIFE )
  • Some tasks still need to be "fine tuned", or missing (no format or lint tasks)

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!

Copy link
Member

@bryceosterhaus bryceosterhaus left a 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?

};

// WrappedComponent.propTypes = {
Copy link
Member

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?

Copy link
Contributor Author

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,
Copy link
Member

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.

Copy link
Contributor Author

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;
Copy link
Member

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?

Copy link
Contributor Author

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);
  }
}, []);

Copy link
Member

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.

Copy link
Contributor Author

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';
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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 {
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Member

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)) {
Copy link
Member

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.

Copy link
Contributor Author

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()}>
Copy link
Member

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.

Copy link
Contributor Author

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;
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just so you know this button is actually an element, but be reassured it has a key

keys

Copy link
Member

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.

@julien
Copy link
Contributor Author

julien commented Dec 20, 2018

Hey @bryceosterhaus,

Thanks for the review, yes the idea was to review the last commit.

@bryceosterhaus
Copy link
Member

@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.

@bryceosterhaus
Copy link
Member

Updated changes look good to me!

@julien
Copy link
Contributor Author

julien commented Dec 26, 2018

@bryceosterhaus thanks again for the review!

@julien julien merged commit 5da5cde into liferay:2.x-develop Dec 26, 2018
@julien julien deleted the feature/react branch February 14, 2019 15:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.