Skip to content
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.

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

Rework ViewElement to open new usages #809

Merged
merged 40 commits into from
Apr 1, 2021

Conversation

TimLariviere
Copy link
Member

@TimLariviere TimLariviere commented Oct 27, 2020

As part of the allocations reduction process, I'm reworking the ViewElement class to become an interface IViewElement.
This will allow for different implementation such as ComponentViewElement (see TimLariviere#25 for more information).

In this example, ComponentViewElement would drastically reduce the number of allocated ViewElement at each update.

@TimLariviere
Copy link
Member Author

Introduced Registrar and DynamicViewElementHandler types.
Those will avoid having to store targetType, create, update and updateAttachedProperties inside each DynamicViewElement instances, reducing the memory footprint of 1 DynamicViewElement.

So this should have a great impact on the memory allocation due to the sheer numbers of DynamicViewElement instantiated throughout the life of an application.

type ViewElementHolder(viewElement: ViewElement) =
let ev = new Event<_,_>()
type ViewElementHolder(viewElement: IViewElement, programDefinition: ProgramDefinition) =
let ev = Event<_,_>()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might also want to populate this event object on-demand (mutable, null initially)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Will take a look if that's possible. Not sure if Xamarin.Forms expects PropertyChanged right after the creation.

Trace: TraceLevel * string -> unit }

and IViewElement =
abstract Create: ProgramDefinition -> obj
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess /// comments on each of these would be good :-) Given the central nature of the interface :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'm planning to put /// comments on all public surface APIs.

member x.SetDispatchThunk v = dispatchImpl <- v

/// Program type captures various aspects of program behavior
type RunnerDefinition<'arg, 'msg, 'model, 'externalMsg> =
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH this should really have always been an interface I think. I made it a record out of deference to the Elmish/Elm origins

Copy link
Member Author

@TimLariviere TimLariviere Nov 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The record did not bother me because it's easy to extend with optional and/or custom behaviors through Program.with....
An interface could do it too I guess, but might not be as simple to use.
I need to think about it.

@dsyme
Copy link
Collaborator

dsyme commented Nov 3, 2020

@TimLariviere I love what you're doing here

@TimLariviere
Copy link
Member Author

Thanks!

@TimLariviere
Copy link
Member Author

TimLariviere commented Nov 5, 2020

This PR also reworks the way we print some debug info to the console, by using a built-in tracing tooling.
This will help fix #307

Runner + Tracing


XF Program


WIP


Registrar/Handler


AttachTarget/DetachTarget


Fix ViewConverters/ViewUpdaters


Fix CodeGen


Fix CodeGen 2


Fix CodeGen 3


Working CounterApp & FabulousWeather samples


Fix other samples except Shell


AllControls


ComponentViewElement


Working external msg for component


Fix merge


Fix merge
@TimLariviere TimLariviere marked this pull request as ready for review April 1, 2021 18:45
@TimLariviere TimLariviere merged commit 86469d0 into fabulous-dev:master Apr 1, 2021
@TimLariviere TimLariviere deleted the componentviewelement branch April 1, 2021 18:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants