Type: feature

The following has been addressed in the PR:

• There is a related issue
• All code has been formatted with prettier as per the readme code style guidelines
• Unit or Functional tests are included in the PR

Description:

Introduces a change to the Outlet API to enable consumers more control over the nodes to render when an Outlet's route has been matched. Instead of providing a static widget, the Outlet accepts a function that returns DNodes the same as a widgets render function.

Outlet now also accepts a generic argument to specify the properties required when using the Outlet in the widget tree. These properties may exactly match the properties of the widget itself, but often widget properties are computed from properties from the router so the Outlets properties could be a subset. The outlets properties are passed as the render functions first argument and the OutletProperties are passed as the second argument to the render function.

interface MyOutletProperties {
    foo: string;
}

const MyOutlet = Outlet<MyOutletProperties>((properties, outletProps) => {
    // properties contains `.foo`
    // outletProps contains router related properties like `params` and `queryParams`
    return w(MyWidget, { bar: outletProps.id, foo: properties.foo });
}, 
{ outlet: 'foo' })

The render function also receives the "type" and a couple of helper function isError and isExact to determine which widget is required to be rendered depending on the match type. Previously the Outlet supported this by overloading the first argument as an object of main, index and error type widgets.

interface MyOutletProperties {
    foo: string;
}

const MyOutlet = Outlet<MyOutletProperties>((properties, outletProps) => {
     if (outletProps.isError()) {
        return w(ErrorWidget, {});
     }
     if (outletProps.isExact()) {
         return w(ExactMatchWidget, {});
     }

     // return undefined when no widget is needed to be rendered based on the match type.
     return undefined;
}, 
{ outlet: 'foo' })

Resolves: #60