Open TysonMN opened 3 years ago
@TysonMN regarding Telerik, they recommended me to use the "trial version":
Trial License The free trial licenses of all Telerik products are fully functional and will work for an unlimited time but with trial error messages (see below) displayed randomly on the page.
Trial Error Messages The trial licenses will occasionally display the following message on your application:
Telerik UI for WPF trial version. Copyright Telerik © 2002-2014. To remove this message, please, purchase a developer version.
More information on their website license page).
That seems fine. Let's have it be a separate executable/project then so that message doesn't also get displayed to people not interested in Telerik.
I found the transition from SingleCounter to NewWindow samples had a learning curve as SingleCounter does not have an App.fs and I was learning the structure of Elmish.WPF solutions. I have a working AnotherNewWindow that consolidates models and functions in Program.fs.
Would that be useful to others?
I have it in a separate branch of course at https://github.com/rfreytag/Elmish.WPF, branch: "Program_only_version_of_NewWindow"
Sure. Share a link to a branch containing your code, and I will take a look.
I found Sample/NewWindow.Core/App.fs hard to read. I have a version in my fork, branch: Adding_fully-specified_parameter_lists
that I find more readable with the following changes:
Every function has fully-specified parameter lists and return values. Readability is improved by not having to hover over function names to see what the function manipulates.
module App
, module Window1
and module Window2
have been renamed module App_Window1
and module App_Window2
so their usage in App.bindings
is not confused with the actual references to Window2
in App.bindings
.
Clarified module App
, module Window1
and module Window2
: get
, set
, and map
so they specify the type on which they operate for readability. They are now respectively:
module App
, module Window1
: get_Window1State1
, set_Window1State1
, and map_Window1State1
andmodule App
, module Window2
: get_Window2
, set_Window2
, map_Window2
.Replaced all usage of function
with explicit match <parameter name> with
in line with adding explicit parameter lists.
I added fully-specified parameter lists to the remaining Sample/NewWindow.Core F# files while I was at it.
Doing this helped me understand what was going on. I hope it will help others adopt Elmish.WPF. I will issue a pull request if you like where I'm going.
@rfreytag Go ahead and open a Pull Request for it. Modify the existing sample and that will make things easier to look at. They all sound good, especially if you found it helpful (empirical testing is the best testing).
Everything I did is what I think is the minimum necessary changes for readability from the original Sample/NewWindow.Core. Perhaps I'm missing your meaning?
@rfreytag I'm sorry, somehow I got it in my head that you had suggested you could make it as a separate example project.
I'd say it looks good exactly as you have it, and you should definitely open a PR.
@marner2 @TysonMN Having finally found the cycles to properly understand NewWindow.Core I am thinking its placement of most of the computation in App.fs is more flexible than putting all the computation in Program.fs (as done in the rest of the Samples).
It shows us novices how one can hand control between multiple Core F# files and multiple modules. Its been a while since you were as new as I. :-)
Would you accept a change that altered Capabilities.Core to also have a terse Program.fs with a main
that essentially calls into functions in App.fs as is done in NewWindow.Core?
That sounds good.
My idea with the Capabilities
sample is that most of the samples would be combined into that one. Does that make sense?
World you like to do that combining?
@TysonMN That makes sense. As you can see I am returning to this after a long absence. Best if I take bites of this as I can and limit my broad commitments for now.
It is gratifying to have contributions evaluated; thank you.
No rush
Is there a possibility to have an example of putting an Elmish.Wpf
example into a functioning F# or C# normal Wpf solution? To show how to partially convert.
That is a reasonable idea. Thanks for suggesting it.
I think improving the existing samples is more important though, so I don't know when (or if) this improvement will happen.
I suggest this example to guide Elmish.WPF newcomers coming from C#+MVVM; it's at least what I would have liked to have as a first tutorial (I think the abstract name says more about the general mindset to have when coming from C#, than a more specific counter-example, which is of course a good next step).
https://github.com/YkTru/Elmish.WPF-Samples-ViewModel/tree/master/ViewModel.Core
There are several improvements that I would like to see the samples. To make it easier for other to help improve the samples, this issue will be an epic with a checklist that I keep this first comment updated with (hopefully) simple tasks.
Primary consolidated sample
I like how Material Design in XAML Toolkit has one sample for WPF that demonstrates everything. We have a project called Capabilities that is intended to be the start of this consolidated sample.
SubModelSeq
binding (merge) performance with and without keysPatterns
Integration with thirds-party controls
If licensing permits, it would be nice to have samples that show how to integrate with third party controls.
Samples that demonstrate entries points
App.xmal
). Advantage: corresponding resource code automatically generated if needed.Related issues and comments