that

As part of #73 methods were added that couldn't be tested due to an update needed in w_common.

Problem

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.

Solution options

1. Keep error logging on, but hide normal lifecycle logs behind a url parameter, w_module.verbose=true

Example

The amount of lifecycle logging before:

After Solution option 1 (notice the length of the scrollbar pill):

Inspired by #110

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

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.

Issue:

We have no pattern for knowing when a module has actually finished loading.

Use case:

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.

Why is this:

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.

Proposed solution:

1. Mark the onLoad function as deprecated and introduce the 'onSetup' function as a functionally equivalent replacement.
2. Everyone migrates to the new hotness known as 'onSetup'.
3. We reintroduce 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

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.

[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

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.

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

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();
}

^