Skip to content

Remove unneccessary abstraction #1015

@linkdotnet

Description

@linkdotnet

Currently we have the following type hierarchy:

classDiagram
    IRenderedFragmentBase <|-- IRenderedComponentBase
    IRenderedFragmentBase <|-- IRenderedFragment
    IRenderedComponentBase <|-- IRenderedComponent
    IRenderedFragment <|-- RenderedFragment
    RenderedFragment <|-- RenderedComponent
    IRenderedComponent <|-- RenderedComponent

note for IRenderedComponent "Has no own methods.\nVirtually the same as IRenderedComponentBase"
Loading

Let's subtract the nonpublic implementation classes for now - that leaves us still with the 4 interfaces we expose.
With #1014 I started to remove one of them (the easy one).

History

The split was to anticipate things like Blazor mobile binding so that we have core types and types that are specific for the specific scenario - like mobile bindings or web.

Usage

How are those types currently used? Basically, we are offering those two types to the user depending on what he is calling

  • IRenderComponent<TComponent> when we call things like RenderComponent so that a user has a strongly typed object that wraps his component under test
  • IRenderedFragment that allows wrapping an "arbitrary" RenderFragment that doesn't necessarily bag a "pre-defined" user component

There are two options we can go from here:

  1. Leave those two basic types - as they deem a good separator between those two worlds
  2. Morph them into something like IRenderedComponent<TComponent?> where TComponent : IComponent (Please note that TComponent? obviously isn't a real constraint it is more about showing that the Instance behind that TComponent might be null)

Personally, I am leaning towards the second case where we abolish literally everything and have one base type representing a component under test, independent of its content.

For that to work, all interfaces have to be merged towards bunit.core. I am leaning out of the window and also questioning whether or not we need bunit.core and bunit.web. I do see the benefit for 3rd party maintainers to built upon bunit.core but I don't have any feeling if people really do that. (Besides they are still able even if we would merge).

Metadata

Metadata

Assignees

No one assigned

    Labels

    input neededWhen an issue requires input or suggestionsneeds designMore design is needed before this issue should result in a feature being implemented.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions