refactor(): value types for directives expecting simple string or string combinations

[vmasek]

This will enable input value completion in IDEs when using fxLayout, fxFlexAlign, fxShowHide and fxLayoutAlign directives

I used supported values from directives API docs in wiki
and also included some that are not mentioned there

• flex- prefixes for start and end
• baseline for LayoutAlign which was not mentioned in wiki fxLayoutAlign-API

---

Tested in WebStorm with Angular Language service enabled.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[googlebot]

CLAs look good, thanks!

[CaerusKaru]

In principle, I have no issue with this. It wouldn't affect the runtime build size because all of this is typed metadata, and it's great for developer experience.

Unfortunately, with #900, we're getting rid of individual inputs in favor of making the custom breakpoints story easier for developers, which I think is more of a benefit of this change.

If there is a way to get this in without changing the @Input type I would be more than happy to discuss/review.

[CaerusKaru]

I've also updated the Wiki for fxLayoutAlign to reflect the baseline input. Thanks for catching that!

[vmasek]

@CaerusKaru I see, is it because of
export class CustomShowHideDirective extends ShowHideDirective ... constructor?
https://github.com/angular/flex-layout/wiki/Breakpoints

It's a pitty that the inputs are removed, it now lacks a type safety and using inputs in metadata decorator is a bad practice according to angular style guide.

I'd like to have a closer look on the possibilities, but I don't fully understand the motivation and changes in mentioned PR. Would you have a time for some intro?

[CaerusKaru]

@vmasek It's not because of the constructor, we're actually refactoring so that you don't need to include one in a custom breakpoint directive as part of #900.

I have two points about type safety and the style guide. For type safety, inputs generally don't require them, especially in our library where most directives accept any type of value and are coerced to the correct type at runtime. We have documentation that provides the options for our users, and while it would definitely be easier to have an inline reference, maybe a better place for that would be the package README (or the module README?).

As for the style guide, it is a general best practice guide for end users, not library authors. Angular Material, for instance, violates many of the style guide core principles, most notably by using the host metadata parameter on practically every directive. It makes it more convenient and maintainable for a more complex codebase, at least in some people's opinions including my own.

If we were to not follow this, and revert back to using Input decorators, we would need to declare n number of Inputs based on each component. If we simply declare an array, we don't need to declare any Inputs, and they all get funneled into central processing by ngOnChanges. This gives us the flexibility of saying ngOnChanges and the inputs array corresponds 1:1 with mediaQuery processing, and all Inputs are strictly for additional functionality (like fxShrink and fxGrow).

This is the motivation behind #900, to reduce complexity and overhead introduced by having a ton of Inputs for each directive, as opposed to centralizing the input functionality to one place. Please head over to #903 for some more explanation and discussion on the issue.

[vmasek]

Thank you, in that case, I am closing this PR, if I manage to come up with some other solution for this, I will discuss it in new PR/Issue.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}