The main.css is not currently being imported or emitted so cannot be used downstream.

When using parade in dist mode tests fail to run due to an error attempting to load a script

The theme table does not currently include pseudo selectors, which would also be useful to document

None of the menu's currently show on mobile, we should pick a pattern such as the horizontal scrolling or hamburger menu and implement

The current Parade configuration generates a left-hand navigation menu based on the configured widget names, but there's no way to group these widget names, e.g. "Layout Widgets", "Form Widgets", etc.

It may be nice to support more advanced menu configuration, especially to-level menu groupings.

The parade config is currently untyped, we should type it for end users.

At the moment widget properties are documented using a convention to find the properties interface. This means that expected properties that are decorated by middleware of mixins need to explicitly added to the widget properties by extending the appropriate interfaces.

We need to change parade to be able to determine the "complete" widget properties interface without needing to use extends each or the interfaces.

As title

Before we would conditionally toggle parts of the runner off when not in docs mode, we now don't have that flag at all so we should create config options to enable/disable parts of the app.

If a widget has no supported theme classes, we should hide the theme table.

When excluding some keys from a base type, as was intended for the constrained input (dojo/widgets#986), the . current getWidgetProperties fails as one of the base type declarations is not an interface declaration and doesn't itself have a getBaseDeclarations method.

It would be nice for things such as form widgets or other types of widgets to be able to group them in the menu. this could be done in the config physically or by some kind of tag.

It would be nice to be able to include a description with each example. A simple solution could be a description property alongside filename and module on the example config object. A more robust solution could be a descriptionFilename property that renders the named markdown file.

The title bar is set to z-index: 1000!important which causes the SidePane widget to be underlayed beneath it. Is there a reason this is set so high? The class is also call z-100 which leads me to think maybe this was a typo?

line in question:

The routes should define page titles so the tab title and browser history don't say "examples" on every page.

In projects with many widgets (even Dojo itself right now) it can be tedious to quickly find a specific widget. It would be nice to support search (maybe an input above the menu items) that is auto-focused on page load.

It would be nice if we can see the local runner like npm start on Pull Requests to see changes. We've done this elsewhere by deploying now.sh.

When creating examples using parade, the css-reset loading by tailwind is leaking into the examples and effecting their appearance. For example; buttons have their borders etc removed by the reset-css so any buttons within an example will have no borders.

I feel like it's common for the widgets developed within a Parade-like environment to also live within GitHub for most consumers. It would be nice to support linking between a GitHub repository and a given Parade instance. This would allow users to click "edit" buttons on examples, for instance, which would take the user to GitHub to fork the repository, etc. This could most likely be driven through configuration.

When theme.compose (@dojo/widgets/middleware/theme NOT in framework) is used to compose themes together with a prefix these classes are not added to the widget classes list in parade.
It would be useful if parade could detail the widgets that can be targeted within a widget via a prefix.
For example, the @dojo/widgets/typeahead uses a menu prefix for the List that it renders but this is not very discoverable unless you look at the code itself.

Currently errors if app loaded without tests.

Parade is currently configured using a single configuration file. This configuration object can get complex, and issues are open to potentially expand the support configuration schema. For reference, the current widgets Parade configuration is over 2100 lines long for 68 widgets.

It would be nice to support local configuration files using a .example.ts suffix, similarly to how test files use an auto-detected .spec.ts extension. This would reduce the size of the global configuration file (which may still be required for settings that are actually global), would increase maintainability, and would be symmetrical with how we currently handle testing.

It would be useful if parade documented the i18n keys used within a widget as it does with properties and children.
This would aid discovery and make it easier for users to pass a different i18nBundle to a widget.

When serving parade examples in watch / serve mode and refreshing the page after a build when on a deep link ie. http://localhost:9999/#widget/date-input/overview the following error can often been seen:

Example.tsx:73 Uncaught TypeError: Cannot destructure property 'properties' of 'widgetProperties[widgetName]' as it is undefined.
    at Example (Example.tsx:73)
    at _createWidget (vdom.ts:2107)
    at _processOne (vdom.ts:1979)
    at _process (vdom.ts:1953)
    at _runProcessQueue (vdom.ts:1747)
    at _runInvalidationQueue (vdom.ts:1719)
    at vdom.ts:1655

At the moment it's possible for an example to a) error and break the entirety of parade b) render things unusually outside of where you'd expect ie the example box (for example a snackbar, slidepane etc). We should try and render the example itself in an iframe, like we already do for the tests

A minior UI issue; when no examples are available for a widget, the divider and white space still rendered. It maybe be slightly cleaner to not render this markup when no examples are present.

A number of repeated elements and widgets are not keyed which throws warnings in the console

The examples are very useful right now, but there's no way to collapse the code pane for what you're currently viewing. Especially if we implement "fullscreen mode" #79, which would further make Parade a development platform as opposed to just a showcase, collapsible panes would also allow the user to "hide" example code they don't care about (especially if they're already working on it locally.)

It's currently hardcoded to @dojo/widgets conventions. We should probably make this configurable

I find myself opening dev tools when using Parade to imitate various screen sizes, especially when using Parade as a development platform. It would be nice to allow examples to be "resized" instantly by clicking on a predetermined "size", e.g. "phone", "tablet", etc. This would only resize the example frame to a predetermined dimension.

The styling is currently written to match @dojo/site, we should offer a more agnostic layout for end users.

Hello,

a quick feature request for this fantastic thing.

User story :
People want to extend widgets with own CSS declarations.
They need to know which keys for which nodes are present for "extra classes" …

Currently parade shows tables for e.g. Properties, Children, Theme –
how about "Keys" ?

It would be nice if we could show widgets being used as Custom Elements in the documentation. I'm not sure how possible this would be for the actual examples, beyond "basic" but even having them work as basic would be nice.

Currently, Parade uses a two-menu navigation approach in which the left navigation menu renders example widget names, and the right navigation menu renders example names and theme variations. As a result, we're losing out on ~400 pixels of screen real estate that's mostly blank on the right side of examples.

It may be nice to improve how Parade lays out its navigation menus:

• Expand widget names on-click to show example names as accordion children to the widget name.
• Move theme selection into the header.
• Remove the right navigation menu altogether.

It would be nice to be able to demonstrate i18n locale switching in the widgets.

Look for Children interfaces and render an additional Children section in the widget documentation.

Doc for dojo/widgets 7.0.0

API documentation generated for widgets that compose TextInput is missing the Children section.

Examples of missing Children sections include:

• ConstrainedInput
• EmailInput
• NumberInput
• PasswordInput

Current menu for sections/widgets does not scroll very easily on desktop as the headers overflow off the screen. For desktop size screens the menu should be shifted to a left side menu to help with navigation.

Based on changes made in dojo/site#183

Parade renders property interfaces (which is awesome) but we do not get code highlighting, which can make them difficult to grok. It would be nice to highlight these too.

The codesandbox link is currently non configurable (it's hardcoded to dojo/widgets). We should provide support for specifying this in the config and disable/remove it if not configured.

It's currently impossible to run parade locally for development. We should add the associated code to be able to run this with @dojo/cli-build-app locally.

There is no way to switch themes currently.

Currently keeps scroll position on page change.

In order for Parade to better serve as a drop-in widget development frontend (outside the scope of a given application, which can be tedious to get running), it may be nice to support full-screen mode for each example. This would allow developers to hide all unnecessary chrome and to focus solely on the UI they are tweaking.

The theme selection should be a query param in the URL so when the page is reloaded the theme selection is retained.