tng / ngqp Goto Github PK

It should be possible to define, e.g., how skipLocationChange and replaceUrl are set. This should be possible globally on module-level as well as on group-level.

• CoC
• License section
• Demo → Website
• Super-small installation
• Getting help

• Have a single release script that takes care of: removing dist, building with prod and base href, running standard-version, publishing to npm and deploying the demo
• How to extract and build API documentation and add to the demo?
• Make sure to copy README + LICENSE

Test it & fix it

What's your idea?

We could provide a Stackblitz starter template which has a small example preconfigured. This could be linked in the README.

The ngqp-demo should document all features, be deployed (Github pages?) and linked in the Github header.

Currently, `combineWith' is required to return a list of "finished" query params. However, it could also be useful to instead return a list of control names + values. This would require that

1. serializers are run on these values
2. combineWith is evaluated recursively

Perhaps introducing this as a separate combineWithValue option would be best since it might make sense to retain both features separately.

This issue serves as a placeholder for future discussion.

This would probably make tests easier and would be good to have for the docs website to show the URL in a local field per example.

We should support controls which can take multiple values (such as a multi-select). On the URL side, this should just use Angular's router functionality for array values.

We need to think about the API for this as it might also affect (de-)serializer signatures. Very likely we at least need some multi: boolean property to also know whether to call get or getAll.

What's your idea?

When using emptyOn, the value is not only used as a default if missing in the URL, but also the parameter is removed from the URL if the form control takes on this value. If we want to avoid the latter, we currently need to create a custom deserializer. Perhaps adding a simple keepEmptyOn: boolean would make this a bit easier to use.

What's your idea?

This would improve the search experience

We need valueChanges on group and control level and have to make sure they emit.

What's your idea?

Router options like replaceUrl are currently set either globally or per QueryParamGroup. We should consider whether we should also allow a third override per QueryParam.

If so, the replaceUrl example should be updated to use this mechanism.

We already track navigations, but maybe worth tracking as events:

• Interactions with the demo browser (send URL, go back)
• Viewing HTML / Typescript code
• Using the TOC
• Switching to the API Docs (not tracked since external)

It should be possible to define a debounce: number property on a QueryParamControl which debounces the change. It needs to be defined still whether the change should be debounced before or after the URL is updated.

The use-case for this is, e.g., a text input search field where it's very likely that a user would want to debounce this, but not other controls (such as dropdowns), so allowing this gives users an easy way to achieve it.

What's your idea?

All the "meat" of the logic is currently handled in QueryParamGroupDirective. As a first step, this should be refactored into a service (which this directive then provides) to decouple the logic from the view directive. A further step would be to have this redirect to some global service which can orchestrate the different groups or whatever together.

Once Angular 7.2.0 lands, we should update the dependency to it and use this.router.getCurrentNavigation().extras.state and navigate(…, {state: {ngqp: true}} to determine whether to ignore a change in the route.

This would replace the current mechanism of using compareWith. We could consider making this optional again as a result.

This issue is meant to coordinate the first release:

• Make a breaking change announcement commit
• Adapt schematics to use v1 for Angular 7

Wrap them into try-catch calls.

Perhaps we can do this by using two @Inputs for writeValue/onChange. Maybe this can even be done as a separate directive.

What's your idea?

We made using forRoot optional since it wasn't easy to get schematics to add it correctly. However, we can take a look at how Ionic does it: https://github.com/ionic-team/ionic/blob/master/angular/src/schematics/add/index.ts

Once in the schematics we do it correctly, we can also force using forRoot to avoid the awkward provider duplication. Perhaps we should also make sure a nice error is thrown if no router adapter is found.

What's your idea?

See: https://compodoc.app/guides/usage.html

• custom name
• customLogo
• GA

There should be some configuration surface that allows changing other parameters when the model of a control changes. The use-case would be pagination where changing certain controls needs to reset the current page.

A first idea is to provide a combineWith: (previousValue: T, currentValue: T) => Params coniguration option on control level.

• Add codecov
• Add codecov badge

Probably involves a custom accessor

What does the bug look like?
The GitHub social button on the landing page works if that's the page you load initially, but once you navigate away and come back it no longer works.

How can this bug be reproduced?

1. Go to https://ngqp.io
2. Navigate to "docs"
3. Click on the logo in the upper left

The GitHub button is now gone and just a link is shown.

What's your idea?

We should consider whether it makes sense to allow dynamically adding and removing QueryParam models to / from a group.

There should be 2–3 issue templates:

1. Feature requests
2. Bug reports
3. Support questions

• Batches
• Information on how to install
• Reference to CONTRIBUTING
• License footer

Look for everything with TODO Documentation and do it.

What's your idea?
The preserveFragment flag should also be configurable both globally and per QueryParamGroup, similar to replaceUrl.

We should expose an interface like QueryParamAccessor (see below) for form controls to implement. Note that this should use an injection token as we might want to provide this on native controls (to be determined).

This would allow using a form control without specifying a (de-)serializer on param control level. If those are specified, they need to take precedence.

A possible interface would look like this:

interface QueryParamAccessor<T> {
    serializeValue: (value: T | null) => string | null;
    deserializeValue: (value: string | null) => T | null;
}

The missing ones are currently:

• NumberValueAccessor (can just exend the default accessor and override the change function)
• RangeValueAccessor (can just extend the default accessor and override the writeValue function)
• CheckboxValueAccessor
• RadioControlValueAccessor
• SelectMultipleControlValueAccessor (only meaningful once #5 is implemented)

The radio one is a bit tricky since here we will have multiple form controls with the same queryParamName. This means we need to properly support using the same name on multiple controls.

(Edit: which should now work)

Rapid prototyping is cool, but we need to ensure we know our library before we ship it, so make sure we have a good test coverage.

Since this is very much related to the stated goal of ngqp, it would make sense to provide some easily accessible information for that even if it isn't directly handled by ngqp.

If we added a separate @ngqp/schematics package to handle ng add, we could determine the Angular version used and install the appropriate ngqp version. This assumes we align the versions with Angular.

What's your idea?

Currently, all properties of QueryParam are "fixed". We should consider for each option whether it makes sense to support changing the configuration dynamically (and implement it).

https://codeburst.io/using-google-analytics-with-angular-25c93bffaa18

https://github.com/ng-bootstrap/ng-bootstrap/blob/master/demo/src/app/shared/analytics/analytics.ts

What's your idea?

https://compodoc.app/guides/tips-and-tricks.html#styling-the-documentation

Allowing to pass an array / rest params rather than an object to the group builder would allow removing the potentially unnecessary duplication of control name and parameter name for users who don't care about this:

builder.group(
  builder.param({/*…*/}),
  builder.param({/*…*/}),
);

Perhaps requires a separate mechanism / refactoring since currently emptyOn is evaluated in the serializer, which is invoked per-value.

What's your idea?

We should avoid type aliases like RouterAdapterOptions and instead use proper interfaces.

The QueryParamGroup (and maybe also QueryParamControl?) should support a patchValue function which allows programmatic changes to the model (and are then reflected in the URL).