Open va-stefanek opened 1 year ago
Run & review this pull request in StackBlitz Codeflow.
@milo526 @va-stefanek can we think on another way to do it without using inheritance and still keep it typed?
@milo526 @va-stefanek can we think on another way to do it without using inheritance and still keep it typed?
I've looked into this and I cannot find a cleaner solution for now.
@NetanelBasal @milo526 we can think of about dedicated function to create dialog definition e.g createDialogDef
which will point into the dialog component class and accept config. Than that definition could be passed to open the dialog. We could define it in scope of same file as our component or in separate one. We can also lazy load that component in scope of that config definition which will reduce bundle size till the time we decide to open it.
e.g
export const dialogDef = createDialogDef({
load: async () =>
(await import(`./test-component`)).TestComponent,
defaultConfig: {
enableClose: true,
minWidth: '626px',
width: '626px',
},
})
and
dialogService.open(dialogDef)
Interesting
@NetanelBasal @milo526 let me know if this is what you are interested in.
I'd love to hear from @milo526, who'll probably be the first consumer.
I'd love to hear from @milo526, who'll probably be the first consumer.
To be fair; this is not what I envisioned when creating the issue.
The configuration is now still outside of the class and a developer could still accidentally or intentionally open the class itself instead of this new definition.
This is not much different from adding a static method on the class and providing that as the argument to the dialogService.open
call (expect from some stricter enforcing of types at the config definition location).
@NetanelBasal any input?
@milo526 what do u think about this approach?
@milo526 what do u think about this approach?
My first question would be, how does this interact with DI? Not able to test this myself right now, but being able to use DI in modals is important to use; in our experience requiring constructor parameters often messes with DI.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Issue Number: #89
What is the new behavior?
Added possibility to define config in scope of component class
Does this PR introduce a breaking change?