SJRK-320: Convert storyTellingServerUI.js code into a component

Metadata

Source
SJRK-320
Type
Task
Priority
Major
Status
Open
Resolution
N/A
Assignee
N/A
Reporter
Gregor Moss
Created
2020-01-16T15:43:57.650-0500
Updated
2020-01-22T17:14:09.600-0500
Versions
N/A
Fixed Versions
N/A
Component
  1. Storytelling Tool UI

Description

In the review process for work on SJRK-255, @@Antranig Basman left the following review comments:

https://github.com/fluid-project/sjrk-story-telling/pull/35#pullrequestreview-270700397

A big problem with the test set up is that this entire component tree leaks between tests, including the UIO instance nested in it. We need to arrange for teardown of the browse component once the fixtures finish. See below -

and

https://github.com/fluid-project/sjrk-story-telling/pull/35#pullrequestreview-270701074

Any time there's a call to loadBrowse we need to arrange for cleanup - I suggest packaging the assertion functions into a reusable utility that as well as making the assertion calls storyBrowse.destroy() once it is done

A slightly cleaner structure would just have one testEnvironment per use of a "page" and then repackage sjrk.storyTelling.loadThemedPage rather than as a standalone function, a definition for a "createOnEvent" subcomponent of a PageLoader component which fires on the completion of the I/O for /stories (and /clientConfig, with boiling, etc.). Then you could rely on the standard teardown of the testEnvironment to arrange for destruction of the PageLoader once you were finished tinkering with it in the fixtures. This might be enough in itself to stop the race on constructing the 2nd and further UIO components into the same page but I will continue to investigate

Address the review comments by creating a new component that will automatically handle loading clientConfig, custom theme files and story data, as well as have its lifecycle managed by Infusion and the IoC test framework.

Comments