-
-
Notifications
You must be signed in to change notification settings - Fork 832
Allow Modal to be used with async-loaded components #618
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -366,10 +366,11 @@ module.exports = WithMatrixClient(React.createClass({ | |
}, | ||
|
||
onCryptoClicked: function(e) { | ||
var EncryptedEventDialog = sdk.getComponent("dialogs.EncryptedEventDialog"); | ||
var event = this.props.mxEvent; | ||
|
||
Modal.createDialog(EncryptedEventDialog, { | ||
Modal.createDialogAsync((cb) => { | ||
require(['../../../async-components/views/dialogs/EncryptedEventDialog'], cb) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder whether it would be better to use the CommonJS There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. agreed, though where have we used commonjs elsewhere? (And it's the callback that makes the difference between the two types of will make it so There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. oh, except that conflicts with my previous point: using the CommonJS syntax would be considerably more verbose, as there is no longer a simple way to pass the component into There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, we use straight 'require' which is CommonJS, although of course now we're moving to ES6 import syntax, but webpack doesn't support this for async loading. And yeah, it does seem to make it quite a chunk more verbose. |
||
}, { | ||
event: event, | ||
}); | ||
}, | ||
|
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 there a reason for callbacks rather than promises here, ooi?
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.
just that
require
(orrequire.ensure
, for that matter) takes a callback, rather than returning a promise. We can't easily wraprequire
with something that returns a promise, because that breaks webpack's static analysis. So ifloader
was expected to be a Promise, we would have to add some nasty boilerplate everywhere we loaded a component asynchronously.IOW: currently we can do:
If instead we had to pass a promise, this would become:
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.
Fair enough, if it makes it simpler then callbacks ftw.