Move the parser to a separate project #172
Conversation
The parser is the only module depending on fparsec. FParsec doesn't compile to JS using Fable because of it's C# dependencies... this was the simplest way I could find to quickly get our system compiling to JavaScript in order for us to make a test anonymizer desktop application based on reference.
sebastian
requested review from
cristianberneanu
and removed request for
cristianberneanu
We don't match on or use the result type anywhere. We are now embracing the exceptions instead ;)
sebastian
force-pushed
the
sebastian/split-out-parser
branch
from
753bce1
to
abd2704
Compare
|
This commit (81ebf46) is going to be a bit hard to review. Sorry. The tests are the same in their functionality. As I moved the tests to the parser test project I no longer had access to the test helpers we had defined in the Core.Tests project. I didn't want to copy them over, nor did I want to move them to a separate tests help lib, so I simplified the tests instead by using the regular |
There was a problem hiding this comment.
As long as we take this approach (Electron desktop app), I don't see a better way to do it.
But seeing the changes needed, I wonder if it wouldn't be simpler to build a regular dotnet GUI application instead. Or build the logic in the command line application and make the GUI a wrapper around that.
I don't think there is a cross platform way of doing this at present? Well, there are a few, but they all seem super clunky? |
My impression was that we are only targeting Windows for the GUI application.
Have you looked into Avalonia? |
Yes 😢 That's what I meant by clunky... but who knows, maybe it's not actually that bad in reality! There is an F# version even: https://github.com/fsprojects/Avalonia.FuncUI Alternatively there is also Uno but I like that even less. That being said, it would be amazing to have a native environment, where we don't have to live in JavaScript. |
|
You know, it could very well be that I am unfair against Avalonia, and that it's a much better fit than I think it is. |
|
OK, I'll give a few of their samples a test drive and see how they feel like. |
|
I played a bit with this GUI library during the weekend and I wasn't left too amazed by it. It is a bit clunky, as you said. I also encountered a few bugs (the scrollbar wasn't rendering properly in one case), the controls are not native, the documentation is lacking good examples, and they have a lot of issues unresolved on Github (over 1100). It would be nice to keep all the code in dotnet and we might make it work for our simple use case, but we'll probably struggle with it. |
Ok, that's not a good start!
Would be great to have everything in dotnet for sure! Would save lots of hassle. I already had some dotnet -> js -> dotnet troubles in the very simple demo I created last week. There are other Electron related alternatives like mentioned by @edongashi like Electron.NET. Unfortunately that doesn't seem very well maintained either. I played with the Electron.NET demo application last week too, but none of the IPC demos worked at all... At least if we go the main electron route we have a stack that is very actively maintained. |
|
The JS ecosystem is much better equipped for:
|
|
Looking at the latest MAUI preview, maybe this ends up something we can use sooner rather than later after all? That is to become the officially sanctioned way of shipping dotnet GUI apps, and is cross platform to boot. That being said: I have no experience with Maui (well, it doesn't really exist yet), nor Xamarin.Forms which it builds on top of... so cannot say anything about the developer experience, or the resulting user experiences once can develop. And F# support always lags behind severely, so we would maybe have to use C# for a while... |
|
Fabulous is the slickest way (I have seen at least) of working with Xamarin.Forms from F#. It uses a Model-View-Update style architecture (like Elm) on top of Xamarin.Forms. It is also "made by Microsoft" (by some definition of that phrase)... Regarding Fabulous + Maui: very much work in progress, or rather "let's wait for Maui and see": fabulous-dev/Fabulous#747 |
The parser is the only module depending on fparsec. FParsec doesn't compile to JS using Fable because of it's C# dependencies... this was the simplest way I could find to quickly get our system compiling to JavaScript in order for us to make a test anonymizer desktop application based on reference.
There is one ugly aspect here which I would love some input on how to address, and that it that the parser types still live in the OpenDiffix.Core project. This is not particularly elegant... These types are used in our analyzer so need to be accessible by OpenDiffix.Core. I could move them to OpenDiffix.Parser, but that in turn would require OpenDiffix.Core to reference OpenDiffix.Parser, which again would mean I would end up pulling in the fparsec dependency, and the transpiling to JavaScript would then end up failing again... Another option would be to move the parser types to a shared "type project", but that seems unnecessarily complicated and just plain noisy.