Skip to content

Follow ups from add unmatched parameters support to our built-in components #10713

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
rynowak opened this issue May 31, 2019 · 2 comments · Fixed by #11580
Closed

Follow ups from add unmatched parameters support to our built-in components #10713

rynowak opened this issue May 31, 2019 · 2 comments · Fixed by #11580
Assignees
@rynowak
Labels
area-blazor Includes: Blazor, Razor Components Done This issue has been fixed enhancement This issue represents an ask for new feature or an enhancement to an existing one
Milestone
3.0.0-preview8

Comments

@rynowak
Copy link
Member

rynowak commented May 31, 2019

While doing #5071 - I left two things untouched that seem like they need some discussion.

Should we remove the Id and Class parameters from EditForm and InputBase<>?

Making these attributes first class makes it obvious that you can set them, and these components have some special handling for class. We need to make a design decision here on what this experience should be like.

Should we rewrite NavLink to use this new feature?

NavLink already functionally has this behaviour. There's a big comment in NavLink about how it was intentionally written at a low level of abstraction that scared me away from making this change. We could do this easily and it would simplify the codes, but I want to make sure I'm not throwing away something valuable.
@rynowak rynowak added area-blazor Includes: Blazor, Razor Components enhancement This issue represents an ask for new feature or an enhancement to an existing one labels May 31, 2019
@rynowak
Copy link
Member Author

rynowak commented May 31, 2019

Note: this sounds like code cleanup, but it's not purely that. We have to make a decision about the API surface and direction for built-in components.

@rynowak
Copy link
Member Author

rynowak commented Jun 3, 2019

See Steve's comments here: #10712 (comment)

@mkArtakMSFT mkArtakMSFT added this to the 3.0.0-preview8 milestone Jun 7, 2019
rynowak pushed a commit that referenced this issue Jun 25, 2019
Clean up of form components
29f373f 
Part of #10713

This change addresses the cleanup of the form components by removing the
Id and Class parameters as explicit parameters. These components will
now propagate the id and class attributes to the created HTML element
without the need for explicit parameters.

Note that we preserve the combining behaviour of class with FieldClass.
@rynowak rynowak mentioned this issue Jun 26, 2019
Merged
rynowak pushed a commit that referenced this issue Jul 1, 2019
@rynowak
Clean up of form components
11b6ac4 
Part of #10713

This change addresses the cleanup of the form components by removing the
Id and Class parameters as explicit parameters. These components will
now propagate the id and class attributes to the created HTML element
without the need for explicit parameters.

Note that we preserve the combining behaviour of class with FieldClass.
rynowak pushed a commit that referenced this issue Jul 5, 2019
Clean up of form components
ee043f6 
Part of #10713

This change addresses the cleanup of the form components by removing the
Id and Class parameters as explicit parameters. These components will
now propagate the id and class attributes to the created HTML element
without the need for explicit parameters.

Note that we preserve the combining behaviour of class with FieldClass.
@rynowak rynowak added Done This issue has been fixed and removed Working labels Jul 5, 2019
rynowak added a commit that referenced this issue Jul 5, 2019
@rynowak
Cleanup of components based on CaptureUnmatchedAttributes (#11580)
002cb51 
Part of #10713

This change addresses the cleanup of the form components by removing the
Id and Class parameters as explicit parameters. These components will
now propagate the id and class attributes to the created HTML element
without the need for explicit parameters.

Note that we preserve the combining behaviour of class with FieldClass.

* Update NavLink to use new features

Simplifies the design of NavLink to use our new features for capturing
unmatched attributes. I can't run the functional tests locally so I hope
this works....
@ghost ghost locked as resolved and limited conversation to collaborators Dec 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@rynowak rynowak

Labels
area-blazor Includes: Blazor, Razor Components Done This issue has been fixed enhancement This issue represents an ask for new feature or an enhancement to an existing one
Projects
None yet
Milestone
3.0.0-preview8
Development

Successfully merging a pull request may close this issue.

Cleanup of components based on CaptureUnmatchedAttributes dotnet/aspnetcore
2 participants
@rynowak @mkArtakMSFT