Open ZheyangSong opened 7 years ago
Yes, I think it makes sense.
Okay. I current have two options in mind:
Option1 Add an @Input() which provide the async data source as Observable. Correspondingly, the existing oneOf
attribute will be used to determine if this async data source should be used (use the async data source, if the oneOf
is a string value, async
. Otherwise, assume the data is provided synchronously and use oneOf
as is).
Option2 detect if the oneOf
attribute is an Observable. If it is, use the attribute's value as asynchronous data source. Otherwise, use the value as synchronous data source.
Would you see anything to improve or better options? Thanks.
I guess I prefer option 2.
Hi,
It's a good enhancement. There is any progress on this feature ?
Megan
Hi @MeganAlexia, I don't have enough time working on this unfortunately. I guess that I can contribute at the beginning of next year... Hope it won't be too late.
Hello, Is there any progress on this feature ? Would love to use it !
Under current component implementation, overriding the default widget can achieve such asynchronicity.
But loading dropdown list options asynchronously (either through Ajax or Rxjs observable stream (a common scenario when using NGRX following the Redux paradigm)) is actually common. Shouldn't it make sense to have the default widget optionally support loading data asynchronously? Then the code won't need to postpone the view rendering until all needed data is fetched.
Thanks.