scaife/widgets

[jhrr]

Modularize the project and port the first set of widgets to the ATLAS reader.

• Modularizes the widgets code. The widgets have their own namespace/store that is cleanly encapsulated using the same pattern as the scaife-skeleton. That namespace is then instantiated in the root explorehomer state tree.
• Ports over widgets:
  • TextSizeWidget
  • TextWidthWidget
  • PassageReferenceWidget
  • PassageAncestorsWidget
  • PassageChildrenWidget
  • And adds Pagination which pages through routes via the graphql metadata payload.
• Uses a rough version of the container/pure components pattern (from redux), but named widgets/components respectively. In this scheme, widgets are 'heavier', structural components that connect to the store to fetch application state, make queries etc., whereas components are 'dumber', store agnostic units that are instantiated within widget templates and just consume props prepared for them by those parent widgets. Widgets in this sense can also be seen as the units of a kind of public interface of scaife-viewer functionality that we want to expose and that occupy slots in the scaife-skeleton.
• Queries the backend for the version metadata in a root action on app load, registers it in the global store and renders base state for the entire app and component tree. Scoped stores within the application can expose aliases to rootGetters if they need to access those slices of state.
• Add linting, formatting and test infrastructure.
• Unittest ported widgets and components.
• Begin abstracting common URN functionality behind a reusable URN class. This module has started to account for dealing with URN hierarchies of rank > 2, as mentioned above.

Notes

• We need to work out some validation on the PassageReference widget, it's easy to put in nonsensical values that return graphql errors.
• ~We should definitely try and update the ATLAS data so we are using URNs with the trailing :. It's already getting a bit confusing working around that.~
• ~We should rationalise our approach to global/shared CSS rules before much longer.~
• ~Very cosmetic but we should camelCase the metadata file on the ATLAS side, getting the occasional jarring underscore popping up in JS attributes.~
• ~https://github.com/scaife-viewer/explorehomer/pull/1#issuecomment-557748033~
• While we are getting pluggable, it might also be nice to develop a scaife-urn library with Python and JavaScript modules that abstracts out all our URN parsing and manipulation needs.

[jtauber]

The fact the Text Width widget has 3 choices, not 4 suggest it's not the latest thing I did for Scaife. Not a blocker but we should update to the latest (the one with the "Full" widget option)

[jtauber]

@paltman you should definitely review this too!

[jhrr]

@paltman you should definitely review this too!

Absolutely! Added as a reviewer.

[jhrr]

The fact the Text Width widget has 3 choices, not 4 suggest it's not the latest thing I did for Scaife. Not a blocker but we should update to the latest (the one with the "Full" widget option)

Oh yep, easily done. Adding to TODO list.

[jhrr]

Yes I definitely agree that the global/scoped CSS situation needs some attention, I'll look into your comments and see what I can sort out.

On Mon, 25 Nov 2019, 20:36 Patrick Altman, notifications@github.com wrote:

@paltman requested changes on this pull request.

Just a few suggested changes. Overall, looks great!

In package.json https://github.com/scaife-viewer/explorehomer/pull/1#discussion_r350375444 :

@@ -21,29 +25,25 @@ "webpack": "^4.41.2" }, "devDependencies": {

• "@babel/core": "^7.0.0-0",

Latest is 7.7.4. Should we use the latest?

In src/App.vue https://github.com/scaife-viewer/explorehomer/pull/1#discussion_r350376621 :