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

UiFramework: Modals in react #11500

Merged
merged 9 commits into from May 3, 2017

Conversation

Projects
None yet
6 participants
@Stacey-Gammon
Contributor

Stacey-Gammon commented Apr 28, 2017

Add modals in the ui framework. Not used yet in angular.

screen shot 2017-04-28 at 2 22 11 pm

Show outdated Hide outdated ui_framework/components/index.js Outdated
const app = uiModules.get('app/kibana', ['react']);
app.directive('toolBarSearchBox', function (reactDirective) {
return reactDirective(KuiToolBarSearchBox);
});
app.directive('confirmModal', function (reactDirective) {

This comment has been minimized.

@w33ble

w33ble May 1, 2017

Member

Are there any future plans for removing this and being able to use React components like we would use Angular components? Or, I'm assuming this gets auto-loaded somewhere in the Angular bootup, so is the plan to no longer import the components we need wherever we need them? I'm a bit out of touch with our "React in Angular" plans...

@w33ble

w33ble May 1, 2017

Member

Are there any future plans for removing this and being able to use React components like we would use Angular components? Or, I'm assuming this gets auto-loaded somewhere in the Angular bootup, so is the plan to no longer import the components we need wherever we need them? I'm a bit out of touch with our "React in Angular" plans...

This comment has been minimized.

@Stacey-Gammon

Stacey-Gammon May 2, 2017

Contributor

It gets imported in public/kibana, so anyone can use them. For ui_framework components, which are generic, it's nice to include them once so you can use them everywhere. For react components that are specific to a certain area, then I would import them where you need them.

So no, no plans to remove this.

@Stacey-Gammon

Stacey-Gammon May 2, 2017

Contributor

It gets imported in public/kibana, so anyone can use them. For ui_framework components, which are generic, it's nice to include them once so you can use them everywhere. For react components that are specific to a certain area, then I would import them where you need them.

So no, no plans to remove this.

Show outdated Hide outdated ui_framework/components/index.js Outdated
Show outdated Hide outdated ui_framework/components/modal/confirm_modal.js Outdated
Show outdated Hide outdated ui_framework/components/modal/confirm_modal.js Outdated
</button>
</div>
</div>
<confirm-modal

This comment has been minimized.

@w33ble

w33ble May 1, 2017

Member

I assume this works because of the react_components.js file, which I'm assuming is auto loaded somewhere else. It's really odd that the src/ui/public/modals/confirm_modal.* code doesn't actually contain a reference to the React component it's using. That's a fair bit of indirection, and someone unfamiliar with the codebase probably won't know to go digging into the ui-framework code to find this, since it's not imported anywhere close to where it's being used.

@w33ble

w33ble May 1, 2017

Member

I assume this works because of the react_components.js file, which I'm assuming is auto loaded somewhere else. It's really odd that the src/ui/public/modals/confirm_modal.* code doesn't actually contain a reference to the React component it's using. That's a fair bit of indirection, and someone unfamiliar with the codebase probably won't know to go digging into the ui-framework code to find this, since it's not imported anywhere close to where it's being used.

This comment has been minimized.

@Stacey-Gammon

Stacey-Gammon May 2, 2017

Contributor

Correct, and yea, it's a good point, but you have to create the angular directives that map to the react component, and I believe there can only be one. So if the react confirm modals in a couple different places, which one is going to register the directive? @weltenwort does that sound accurate?

I tried to find the original discussion for where this model came from, and it appears in the very first react icons PR (#10247), but couldn't find the discussion. Perhaps it was offline - @kjbekkelund or @cjcenizal, do you remember us discussing this?

@Stacey-Gammon

Stacey-Gammon May 2, 2017

Contributor

Correct, and yea, it's a good point, but you have to create the angular directives that map to the react component, and I believe there can only be one. So if the react confirm modals in a couple different places, which one is going to register the directive? @weltenwort does that sound accurate?

I tried to find the original discussion for where this model came from, and it appears in the very first react icons PR (#10247), but couldn't find the discussion. Perhaps it was offline - @kjbekkelund or @cjcenizal, do you remember us discussing this?

This comment has been minimized.

@kimjoar

kimjoar May 2, 2017

Contributor

Not sure — I'm not that knowledgeable about our Angular setup. I also agree with @w33ble (if it's not too painful to move in that direction)

@kimjoar

kimjoar May 2, 2017

Contributor

Not sure — I'm not that knowledgeable about our Angular setup. I also agree with @w33ble (if it's not too painful to move in that direction)

This comment has been minimized.

@weltenwort

weltenwort May 3, 2017

Contributor

yes, the angular directive is globally registered in the body of
react_component.js:

app.directive('confirmModal', function (reactDirective) {
  return reactDirective(KuiConfirmModal);
});

Since javascript modules are singletons, it will only be executed once, no
matter how often that file is imported. If a directive of the same name is
registered again in some other place, the order of execution of the two
statements matters. The last directive definition wins.

All directives are global in an angular 1 app (as are services, filters,
etc...). I don't think there's a way around that. That's one of the things
angular 2 does better (and react, of course). The import and the usage will
always be in separate files, because you cannot import anything in an angular
template.

@weltenwort

weltenwort May 3, 2017

Contributor

yes, the angular directive is globally registered in the body of
react_component.js:

app.directive('confirmModal', function (reactDirective) {
  return reactDirective(KuiConfirmModal);
});

Since javascript modules are singletons, it will only be executed once, no
matter how often that file is imported. If a directive of the same name is
registered again in some other place, the order of execution of the two
statements matters. The last directive definition wins.

All directives are global in an angular 1 app (as are services, filters,
etc...). I don't think there's a way around that. That's one of the things
angular 2 does better (and react, of course). The import and the usage will
always be in separate files, because you cannot import anything in an angular
template.

This comment has been minimized.

@Stacey-Gammon

Stacey-Gammon May 3, 2017

Contributor

In that case, I think we should stick with this path, so we ensure modules from the uiFramework are only morphed into directives once.

In either case, if we want to have a longer discussion about this, I say we move it out of this specific PR since it's not something new that this PR introduced.

@Stacey-Gammon

Stacey-Gammon May 3, 2017

Contributor

In that case, I think we should stick with this path, so we ensure modules from the uiFramework are only morphed into directives once.

In either case, if we want to have a longer discussion about this, I say we move it out of this specific PR since it's not something new that this PR introduced.

This comment has been minimized.

@w33ble

w33ble May 3, 2017

Member

I say we move it out of this specific PR since it's not something new that this PR introduced

Agreed. I'm very much against auto-loading modules on startup, we used to do that, and it got very messy; explicit imports are much easier to understand. I don't know why the auto-loading stuff has come back and why there hasn't been a strong push against it. But that's not a conversation for this PR, and I'm glad to see it hasn't stopped it from progressing. I was just trying to understand our plans around the Angular+React stuff.

@w33ble

w33ble May 3, 2017

Member

I say we move it out of this specific PR since it's not something new that this PR introduced

Agreed. I'm very much against auto-loading modules on startup, we used to do that, and it got very messy; explicit imports are much easier to understand. I don't know why the auto-loading stuff has come back and why there hasn't been a strong push against it. But that's not a conversation for this PR, and I'm glad to see it hasn't stopped it from progressing. I was just trying to understand our plans around the Angular+React stuff.

@cjcenizal

This is awesome, just had a few requests and questions.

Show outdated Hide outdated ui_framework/components/modal/_modal.scss Outdated
Show outdated Hide outdated ui_framework/components/modal/confirm_modal.js Outdated
Show outdated Hide outdated src/ui/public/modals/confirm_modal.html Outdated
Show outdated Hide outdated ui_framework/components/modal/confirm_modal.js Outdated
Show outdated Hide outdated ui_framework/components/modal/confirm_modal.js Outdated
Show outdated Hide outdated ui_framework/components/modal/confirm_modal.test.js Outdated
Show outdated Hide outdated ui_framework/components/modal/confirm_modal.test.js Outdated
Show outdated Hide outdated ui_framework/components/modal/modal.js Outdated

@w33ble w33ble self-assigned this May 1, 2017

@pugnascotia

This comment has been minimized.

Show comment
Hide comment
@pugnascotia

pugnascotia May 2, 2017

Just curious - was the react-overlays package considered at all?

pugnascotia commented May 2, 2017

Just curious - was the react-overlays package considered at all?

@Stacey-Gammon

This comment has been minimized.

Show comment
Hide comment
@Stacey-Gammon

Stacey-Gammon May 2, 2017

Contributor

@pugnascotia I haven't looked at that one. https://github.com/tajo/react-portal has been brough tup, but due to the react embedded in angular nature of this, I'm not sure we can take advantage of it just yet. Once we have a react component that needs to use the react modals, we'll take another look, but for right now, we can't get too fancy because of the angular side of things. At least that is my understanding of it.

Contributor

Stacey-Gammon commented May 2, 2017

@pugnascotia I haven't looked at that one. https://github.com/tajo/react-portal has been brough tup, but due to the react embedded in angular nature of this, I'm not sure we can take advantage of it just yet. Once we have a react component that needs to use the react modals, we'll take another look, but for right now, we can't get too fancy because of the angular side of things. At least that is my understanding of it.

@w33ble w33ble removed their assignment May 2, 2017

@w33ble

Down with React.PropTypes

Show outdated Hide outdated ui_framework/components/modal/modal.js Outdated
Show outdated Hide outdated ui_framework/components/modal/modal_body.js Outdated
Show outdated Hide outdated ui_framework/components/modal/modal_body_text.js Outdated
Show outdated Hide outdated ui_framework/components/modal/modal_footer.js Outdated
Show outdated Hide outdated ui_framework/components/modal/modal_header.js Outdated
Show outdated Hide outdated ui_framework/components/modal/modal_header_title.js Outdated
Show outdated Hide outdated ui_framework/components/modal/modal_overlay.js Outdated
@w33ble

w33ble approved these changes May 2, 2017

@cjcenizal

LGTM!

@Stacey-Gammon

This comment has been minimized.

Show comment
Hide comment
@Stacey-Gammon

Stacey-Gammon May 3, 2017

Contributor

Build failure seems unrelated:

INFO - ecMoIzc - meta_data_create_index_service - [.kibana] creating index, cause [api], templates [], shards [1]/[1], mappings [_default_, index-pattern, server, visualization, search, timelion-sheet, config, dashboard, url]
     └- ✖ fail: " "before each" hook: global before each for "should show the kibana plugin as ready""
     │        Service Unavailable
     │         :: {"path":"/.kibana/config/6.0.0-alpha1","query":{},"statusCode":503,"response":""}
     │         at respond (node_modules/elasticsearch/src/lib/transport.js:295:15)
     │         at checkRespForFailure (node_modules/elasticsearch/src/lib/transport.js:254:7)
     │         at HttpConnector.<anonymous> (node_modules/elasticsearch/src/lib/connectors/http.js:157:7)
     │         at IncomingMessage.bound (node_modules/elasticsearch/node_modules/lodash/dist/lodash.js:729:21)
     │         at endReadableNT (_stream_readable.js:974:12)
     │         at _combinedTickCallback (internal/process/next_tick.js:80:11)
     │         at process._tickDomainCallback (internal/process/next_tick.js:128:9)
     │       
Contributor

Stacey-Gammon commented May 3, 2017

Build failure seems unrelated:

INFO - ecMoIzc - meta_data_create_index_service - [.kibana] creating index, cause [api], templates [], shards [1]/[1], mappings [_default_, index-pattern, server, visualization, search, timelion-sheet, config, dashboard, url]
     └- ✖ fail: " "before each" hook: global before each for "should show the kibana plugin as ready""
     │        Service Unavailable
     │         :: {"path":"/.kibana/config/6.0.0-alpha1","query":{},"statusCode":503,"response":""}
     │         at respond (node_modules/elasticsearch/src/lib/transport.js:295:15)
     │         at checkRespForFailure (node_modules/elasticsearch/src/lib/transport.js:254:7)
     │         at HttpConnector.<anonymous> (node_modules/elasticsearch/src/lib/connectors/http.js:157:7)
     │         at IncomingMessage.bound (node_modules/elasticsearch/node_modules/lodash/dist/lodash.js:729:21)
     │         at endReadableNT (_stream_readable.js:974:12)
     │         at _combinedTickCallback (internal/process/next_tick.js:80:11)
     │         at process._tickDomainCallback (internal/process/next_tick.js:128:9)
     │       

Stacey-Gammon added some commits Apr 21, 2017

Add tests
- Relies on #10821 getting
checked in first for commonHtmlProps
Use the react version of a confirmation modal
- Can’t use the modalOverlay or it would be two nested react roots, due
to the way it’s embedded in angular.
fix confirm_modal_promise tests
I have no idea why the introduction of react would cause this to fail
as it was, but for some reason, grabbing the button reference has to be
after the digest loop.
@kimjoar

kimjoar approved these changes May 3, 2017

@Stacey-Gammon Stacey-Gammon merged commit 8fca519 into elastic:master May 3, 2017

2 checks passed

CLA Commit author has signed the CLA
Details
kibana-ci Build finished.
Details

Stacey-Gammon added a commit to Stacey-Gammon/kibana that referenced this pull request May 3, 2017

UiFramework: Modals in react (elastic#11500)
* Reactify the confirmation modal

Up next: jest tests

* Add tests

- Relies on elastic#10821 getting
checked in first for commonHtmlProps

* Don't include the overlay as part of the confirm modal component

* Use the react version of a confirmation modal

- Can’t use the modalOverlay or it would be two nested react roots, due
to the way it’s embedded in angular.

* Add snapshots

* Fix tests

* fix confirm_modal_promise tests

I have no idea why the introduction of react would cause this to fail
as it was, but for some reason, grabbing the button reference has to be
after the digest loop.

* Address code review comments

* switch over the remaining React.PropType references (in the modals dir anyway)

Stacey-Gammon added a commit that referenced this pull request May 3, 2017

UiFramework: Modals in react (#11500) (#11585)
* Reactify the confirmation modal

Up next: jest tests

* Add tests

- Relies on #10821 getting
checked in first for commonHtmlProps

* Don't include the overlay as part of the confirm modal component

* Use the react version of a confirmation modal

- Can’t use the modalOverlay or it would be two nested react roots, due
to the way it’s embedded in angular.

* Add snapshots

* Fix tests

* fix confirm_modal_promise tests

I have no idea why the introduction of react would cause this to fail
as it was, but for some reason, grabbing the button reference has to be
after the digest loop.

* Address code review comments

* switch over the remaining React.PropType references (in the modals dir anyway)

@Stacey-Gammon Stacey-Gammon deleted the Stacey-Gammon:modals-in-react branch May 3, 2017

Dreadnoth added a commit to Dreadnoth/kibana that referenced this pull request Aug 8, 2017

UiFramework: Modals in react (elastic#11500) (elastic#11585)
* Reactify the confirmation modal

Up next: jest tests

* Add tests

- Relies on elastic#10821 getting
checked in first for commonHtmlProps

* Don't include the overlay as part of the confirm modal component

* Use the react version of a confirmation modal

- Can’t use the modalOverlay or it would be two nested react roots, due
to the way it’s embedded in angular.

* Add snapshots

* Fix tests

* fix confirm_modal_promise tests

I have no idea why the introduction of react would cause this to fail
as it was, but for some reason, grabbing the button reference has to be
after the digest loop.

* Address code review comments

* switch over the remaining React.PropType references (in the modals dir anyway)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment