Skip to content
This repository has been archived by the owner on Jul 30, 2018. It is now read-only.

Convert to use TS2.2 Class Mixins over dojo/compose #326

Merged
merged 15 commits into from
Feb 8, 2017

Conversation

agubler
Copy link
Member

@agubler agubler commented Feb 7, 2017

Type: feature

The following has been addressed in the PR:

  • There is a related issue
  • All code matches the style guide
  • Unit or Functional tests are included in the PR

Description:

Convert widget-core to use TS2.2 class mixins instead of dojo/compose

There are a couple of interesting changes included

  1. The baseTheme property for the Themeable mixin is set via a class decorator (@theme exported from Themeable)
  2. The “result” from using the class Mixins requires a generic to define the Widget’s properties class MyWidget extends ThemeableMixin(WidgetBase)<MyWidgetProperties> and excluding this does actually provide a pretty obscure error No base constructor has the specified number of type arguments. along with a few others.
  3. I’ve removed the default export for all base, mixin and main classes in place of named exports (This is personal preference, so we can debate this potentially)
  4. The constructor argument for any widget is now just properties, the WidgetOptions class/interface has been removed.
  5. Allowed pascal casing for variables, mainly because the result can be a class in cases like const Projector = ProjectorMixin(Button);

Items to follow up on:

  1. A generic solution for decorating the prototype with attributes, eg. provide an object bag from widget base that attributes get set to and then copied from for usage.
  2. Decorators to add functions to a list used by widget base for "property specific diffs" and "render decorators". This will enable us to move away from strict regular expressions.
  3. Need to check the order that "decorator" functions get applied, should work back up the inheritance chain.
  4. Type doc corrected/added where appropriate

Resolves #327

@codecov-io
Copy link

codecov-io commented Feb 7, 2017

Codecov Report

Merging #326 into master will not impact coverage by -1.5%.

@@            Coverage Diff            @@
##           master     #326     +/-   ##
=========================================
- Coverage   98.78%   97.28%   -1.5%     
=========================================
  Files          16       14      -2     
  Lines         656      663      +7     
  Branches      110      107      -3     
=========================================
- Hits          648      645      -3     
- Misses          1        2      +1     
- Partials        7       16      +9
Impacted Files Coverage Δ
src/customElements.ts 98.52% <100%> (+0.02%)
src/bases/Destroyable.ts 100% <100%> (ø)
src/d.ts 100% <100%> (ø)
src/bases/Evented.ts 100% <100%> (ø)
src/registerCustomElement.ts 95.45% <100%> (ø)
src/FactoryRegistry.ts 100% <100%> (ø)
src/mixins/FormLabel.ts 100% <100%> (ø)
src/util/DomWrapper.ts 83.33% <83.33%> (ø)
src/mixins/Registry.ts 92.3% <92.3%> (ø)
src/mixins/Stateful.ts 93.33% <93.33%> (ø)
... and 12 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c1e8803...0fc1c33. Read the comment docs.

@agubler agubler changed the title WIP/POC Widgets TS2.2 Mixins Converted Widgets to use TS2.2 Class Mixins over dojo/compose Feb 7, 2017
@agubler agubler changed the title Converted Widgets to use TS2.2 Class Mixins over dojo/compose Convert to use TS2.2 Class Mixins over dojo/compose Feb 7, 2017
@mwistrand
Copy link
Contributor

The i18n-specific changes look good. 👍

@rorticus
Copy link
Contributor

rorticus commented Feb 8, 2017

Custom element stuff looks good 👍

/**
* Register handles for the instance that will be destroyed when `this.destroy` is called
*
* @param {Handle} handle The handle to add for the instance
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: remove types from comments as per guidelines

Copy link
Member Author

@agubler agubler Feb 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a note that we need to follow up on tsdoc throughout the repo.

readonly projectorState: ProjectorState;
}

export function ProjectorMixin<T extends WidgetConstructor>(base: T): T & Constructor<Projector> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason this isn't the default export? Same goes for WidgetBase I think.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have done this for all classes, it's a topic for discussion i guess but I you'll rarely just use the default.

/**
* WidgetBase constructor type
*/
export type WidgetConstructor = new (...args: any[]) => WidgetBase<WidgetProperties>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to write this as

export type WidgetConstructor = Constructor<WidgetBase<WidgetProperties>>;

?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that absolutely makes sense @maier49, do you mind if we fix the up in a follow up PR?

@agubler agubler added this to the 2017.02 milestone Feb 8, 2017
@agubler agubler self-assigned this Feb 8, 2017
@agubler agubler merged commit 57fddfc into dojo:master Feb 8, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants