workiva / w_module Goto Github PK
View Code? Open in Web Editor NEWBase module classes with a well defined lifecycle for modular Dart applications.
License: Other
Base module classes with a well defined lifecycle for modular Dart applications.
License: Other
Looks to me like w_flux isn't being used as a dependency, let's remove it from the pubspec.yaml to reduce version contention
that
Issue raised in a PR with reference to this code snippet:
window.onBeforeUnload.listen((BeforeUnloadEvent event) {
// can the app be unloaded?
ShouldUnloadResult res = permissionEditor.shouldUnload();
if (!res.shouldUnload) {
// return the supplied error message to block close
event.returnValue = res.messagesAsString();
} else if (browser.isIe) {
// IE interprets a null string as a response and displays an alert to
// the user. Use the `undefined` value of the JS context instead.
// https://github.com/dart-lang/sdk/issues/22589
event.returnValue = js.context['undefined'];
}
}});
Response to consider:
We definitely don't want to rely on the consumer to add that window.onBeforeUnload
chunk module by module.
Execution of the onShouldUnload bit would be executed automatically if the permissionEditor
module were added as a childModule of the consumer's shell, but depending on API usage, maybe that doesn't make sense in all cases. Even then, Truss isn't doing anything automatically at the moment that registers the window.onBeforeUnload
handling.
I think you're right that we should add some convenience methods to w_module and / or Truss to help wire these things up. I'm not sure if we want to enforce automatic registration of all shells with the window.onBeforeUnload
handler, but we could certainly add a static method that helps (maybe something like Module.registerWindowShouldUnloadHandler(myModule)
- need a better name). The static method could be used by Truss shells by default (maybe) and could also be used by standalone modules like Permissions Editor
to register the same sort of behavior without involving the shell module hierarchy in the matter.
We have no pattern for knowing when a module has actually finished loading.
I'd like to have this option so that we can track app-startup. If we can know when an individual module has finished loading, then we can know when a collection of them have (aka our app)
This would also help to understand the time needed for experiences to load.
Although our onLoad function returns a future (implying consumers will be informed of async load-related work being completed), when coupled with invoking actions, there is no way to know that any re-rendering has completed as a result of those initial actions being invoked.
onLoad
and it returns a future that completes once any state changes invoked from onSetup have propagated / re-rendered.Seeking feedback @trentgrover-wf @evanweible-wf @maxwellpeterson-wf @sebastianmalysa-wf @srinivasdhanwada-wf @jayudey-wf
import 'package:w_module/w_module.dart' show ViewModule;
@GenerateDeferred
class ExampleModule extends ViewModule {
ExampleApi get api => _api;
ExampleEvents get events => _events;
ExampleApi _api;
ExampleEvents _events;
ExampleModule() {
_api = new ExampleApi();
_events = new ExampleEvents();
}
buildComponent() => ...;
}
class ExampleApi {
void doThings() {
..
}
Stuff makeStuff() {
..
}
}
class ExampleEvents {}
The @GenerateDeferred
annotation would use sourcegen to create the following class:
import 'package:example/example.dart' deferred as module;
class ExampleModuleDeferred implements ExampleModule {
Object get api => _module.api;
Object get events => _module.events;
bool hasBeenLoaded = false;
ExampleModule _module = module;
Future onLoad() async {
if (!hasBeenLoaded) {
await module.loadLibrary();
hasBeenLoaded = true;
}
}
buildComponent() => _module.buildComponent();
}
^
As part of #73 methods were added that couldn't be tested due to an update needed in w_common.
From @dustinlessard-wf :
Do we have an idea of how the onLoad Future should be treated in the case where a caller requests it after the module has already been loaded? I expect the caller would be provided a future that immediately completes. If so, we may want our examples to show a pattern for achieving that.
From Trent:
My initial instinct would be that this case could be managed by a specific module's implementation pretty easily (keep track of an _isLoaded boolean and short circuit early within onLoad depending on its value), but I'll file a separate issue for that to investigate / consider whether a standard mechanism should be provided instead.
Module lifecycle logs are pretty noisy. They are hard to filter, also. If you filter out console logs that have either w_module or LifecycleModule in them, you wipe out many exceptions, because most of our ecosystem extends from LifeCycleModules.
w_module.verbose=true
The amount of lifecycle logging before:
After Solution option 1 (notice the length of the scrollbar pill):
Inspired by #110
Currently there's a lib/
and web/
directory in example/
which isn't standard. If there's only one example, the index.html should be at the top of example/
. If there will be multiple examples, then we should provide a top-level index.html to serve as a landing page.
[9:50 AM] Alan: does onLoad require you to return a future?
[9:51 AM] Trent: only if you're doing async stuff in there that you want the load method to wait on
if your onLoad body is all synchronous stuff it should be fine without returning a future
[9:53 AM] Alan: If I don't return a future I'm hitting a NPE here: https://github.com/Workiva/w_module/blob/master/lib/src/lifecycle_module.dart#L73
[9:54 AM] Alan: If I return new Future.value() it works fine
[9:55 AM] Trent: shoot...that's my bad then
[9:56 AM] Trent: changed that from async / await to completers because of a different issue in dart 1.13 and the await stuff must have been what swallowed the need for an explicit future there
interim solution = add async
keyword to onLoad method signature to implicitly return a future
The reject module in the example allows for user re-direction without an alert. It should be alerting if the user tries to navigate to another tab or close the browser window. The reject module is working as expected in Dartium.
screencast of issue, http://screencast.com/t/4hSYnac4l
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.