Fabulous: Provide a way to get at the underlying Xamarin control

[kevinha]

Please. Use case is showing the DatePicker dialog from a different control such as a button or icon. This is done by calling Focus() on the Xamarin DatePicker control. I don't think a 'focus' attribute is applicable here as it would require Fabulous to track the state of the dialog. Access to the Xamarin control may also be useful for animation up the until the proper solution for animation has been implemented.

[Zaid-Ajaj]

This is similar to Refs in React very important mechanism for interop with the original DOM element: allows for animations, third-party library support and custom incremental-update logic (among other uses)

[dsyme]

Yes, we need this for #183 and #182

[kevinha]

Also would make it easier to work around some control shortcomings, e.g. TimePicker lack of 'TimeChanged' callback could be solved with PropertyChanged callback without recourse to a rendering.

[TimLariviere]

I completely agree that we need this.
But I also think we should emphasize on discouraging its use, in the docs.

For example, using it to avoid making a CustomRenderer is a bad practice for me.
This feels really hacky.

[dsyme]

@TimLariviere Agreed. I looked at the react docs and they do a pretty good job of striking the right balance.

[kevinha]

@TimLariviere agreed it is hacky and should be discouraged but I emphasise "workaround". I am so impressed with how productive Fabulous is but if I needed to write a custom renderer right now that would really put the brakes on and I would need a workaround while I learnt those skills or hoped that someone else could provide a solution.

[dsyme]

@TimLariviere There are several designs we could use for this.

One would be a created event handler for every control.

Another would be to try to do something more html/react-like and use some kind of ref property (a string) which is a handle usable with a getref function that can look up the latest value of the control in the overall view. Xamarin Forms already have AutomationId - see https://docs.microsoft.com/en-us/dotnet/api/xamarin.forms.element.automationid?view=xamarin-forms and perhaps that should be used, renamed to "id".

Or we could do both

[TimLariviere]

I like the idea of a ref handle.
This would be easier to use in most cases compared to the created callback.
It would also prevent common mistakes

• Accessible only in the local scope, no need for global mutable fields to store the value. (memory leaks)
• tryGetRef to prevent access to an element that has been destroyed, or not yet created.

[dsyme]

• Accessible only in the local scope, no need for global mutable fields to store the value. (memory leaks)

I think the Refs would typically have long lifetime. But they could hold weak handles to the items, so no leaks

[dsyme]

This is now implemented through either the created callback or by using ViewRef, see the brief docs on ViewRef https://fsprojects.github.io/Fabulous/views-animations.html#viewrefs

[draganjovanovic1]

@dsyme, do you have timeline for new NuGet release? Thanks.

[TimLariviere]

@draganjovanovic1 It should be available before tonight if I find time.

[draganjovanovic1]

@TimLariviere, that was fast! Thank you! 🥇