Maui CommunityToolkits reliance on Maui's [InternalsVisibleTo] and building custom components

[durandt]

Hi,

Because of Maui CommunityToolkit's reliance on accessing internal MAUI APIs, one cannot simply copy and customize some components into another project since it won't build.

What would be the recommended way to build and integrate custom controls/components, based on existing Maui CommunityToolkit's controls/components, ahead of submitting them to the project as PRs?
Is forking the repository and adding a code dependency from our Maui app to the forked repo instead of using the NuGet package the only alternative? The downside being having to pull patches (vs updating NuGet dependencies).

The use-case is that I want to try to build a bottom-sheet control/component base on the Popup implementation.

Best regards,

[bijington]

@durandt In an ideal world we would love a bottom sheet implementation in the toolkit see #143

As for getting the functionality built into your own project, what things are internal that you cannot access? One option would be to continue the discussion I linked to and we look into what you are wanting to achieve, I suspect it will benefit others so it has potential for the toolkit. If this is he approach then it would be easiest to fork and build into the toolkit while using the sample app to test it out.

I don't like to advocate for forking and releasing that way mainly due to the patching complications that you mentioned.

[durandt]

Thank you for your quick answer @bijington and for pointing out the existing discussion (I missed that as I was first looking for it among the issues).

Internals

Popup uses PageExtensions.GetCurrentPage that is internal (albeit easy to copy).
Popup implements IWindowController and IPropertyPropagationController that are internal, so that's where the trouble begins.
I should probably be able to just subclass Popup and work with Handlers and Behaviors but I wanted to try to start from the Popup code and learn how the Maui Community Toolkit controls work by running the whole thing.

Going forward

We want to launch our app by the summer and should be able to build our own, simple* Bottom Sheet using a fork and simultaneously participate in the discussion and implementation in #143 so that we can switch to it when released. (*simple because we now that we only want to support Android and iOS and bottom-up appearing. It's always easier to create a component that work for your use-case than to release it to the world)(EDIT: We were also able to frame that our Bottom Sheet would only offer three sizes, about 40%, 70% and 90% of screen height, simplifying a lot the dynamic sizing issue)

[bijington]

I see your issue. I believe your approach sounds like a pragmatic one to suit your needs. I am not sure what the best approach would be then. I guess you can technically fork the repo, modify it and refer to the output of that fork for your development. It would be great to hear how your development goes!

[durandt]

Haha oops I missed that I could reply on your reply.

It would be great to hear how your development goes!

Will do! Right now it goes slowly and a lot of frustration (had to work on other tasks, long time no-worked with iOS, MAUI contribution learning curve, slow building times due to corporate configuration issue with Microsoft Defender, ...) but I will keep you updated!

[durandt]

@bijington I have come most of the way for my needs on iOS (minus some minor enhancements, fixes and refactoring) if you want to check it out: https://github.com/durandt/Maui-CommunityToolkit/tree/feature/bottom-sheet

[durandt]

Basic functionality in Android too now, though crappier code and a bit more limited functionality. (see commit messages)

[CliffAgius]

Closed and answered