Back to Questions
2.3k
views13
comments
Demo of extensive templating and reactive HTML on Try WebSharper
websharperui.next

As promised to Adam long time ago, I have put some pieces of my ongoing F#/WebSharper learning experience onto Try WebSharper. Just some fun stuff around a puzzle solver, but I think it shows some of the power of WebSharper. Thanks to the amazing WebSharper team for creating WebSharper and for delivering great support!

.

Is it only the implementation of the GUI part, the solver isn't included, is it? Is just the result of the solver for each step taken as input or effectively computed here? I imagine that the solver algorithm would make sense on the server, completely in F# and not in JavaScript on the browser/client, but I can be wrong and I may have misintepreted the code at a first, quick glance. I'm asking more about the principles and the architecture of the solution (what is suggested to transpile to JavaScript on the client and what is better to keep in F# on the server) than about the specific low level details of the example.

By on 1/10/2018 12:52 AM ()

Yes, you are right. The "Reviewer" only loads serialized solutions and displays them for review. The complete "Creator" would a) stress try.websharper even more and is b) not yet ready for sharing. I plan to put it on github as soon as it has reached a certain maturity.

The Creator shows, next to the review board and tree also an Editor board where you can edit (or create) the original puzzle. As soon as you change an entry there, the solution is recalculated for the new problem (and you can watch the solution tree grow, again based on Websharper's reactive html).

But even the Creator is pure client code. Which is of course much slower than a server solution could be (actually by a factor of 10). But still fast enough (about 20 ms per solution node on my laptop). Why client only? Because a) the whole project is about learning F# and Websharper, and I wanted to also find out what is possible client-side. And (more important) b) I am not a service provider, but a for-fun software developer. Therefore I prefer the users to provide the compute power ;-).

By on 1/10/2018 2:49 AM ()

(Hi Martin - can you post that as a new snippet from under your Try WebSharper account? Right now it's an anonymous snippet and it recompiles every time someone views it. Thanks!)

By on 1/9/2018 10:50 AM ()

Yes, sorry. I saw too late that I was not logged in, and then thought it would not make a big difference. I have re-posted it under my account. Will you delete the old one? I don't think I can do that.

By on 1/9/2018 12:41 PM ()

Thanks! Will ask our admin to delete the anonymous snippet tomorrow. Also, I updated the link in your topic above to point to the embedded version (which makes the snippet available without the code assistance features - but it loads quicker.)

By on 1/9/2018 3:38 PM ()

Thanks. I didn't know the embed option. Looks very nice! (Like made for my page design :-))

Can I still change the code through the normal try.websharper page?

By on 1/10/2018 3:04 AM ()

Yes, changes made there will reflect in the embedded view.

By on 1/10/2018 9:42 AM ()

Wow, that is quite a nice complex solver algorithm and visualization. Try WebSharper takes quite a bit on it to compile, so it is also a good stress test for optimizations to come, thanks a lot!

Quick note:

1
2

[<assembly: JavaScript>]
do ()

works on try.websharper too, to make all the separate annotations unnecessary.

By on 1/9/2018 8:48 AM ()

The real solver is not even in it - it just re-plays stored solutions. And thanks for the note, I was not aware that this is possible.

By on 1/9/2018 1:22 PM ()

Actually, if I use the assembly level attribute, Firefox reports:

1
2

SyntaxError: unterminated string literal       compile:673:17
SyntaxError: illegal character       compile:673

and Chrome, in addition, has complaints around loading Bootstrap

By on 1/9/2018 1:38 PM ()

We have deployed some fixes to try.ws, handles too big websocket messages better, gives an explicit warning instead of websockets hanging up.

Still your snippet is too big bc of all the data for our limit. Can you try a trick like in http://try.websharper.com/snippet/JankoA/00009d and grab your data with ajax? (this uses D3, but JQuery.Ajax should do the job nicely too)

By on 1/12/2018 9:44 AM ()

Thanks for the update! I have for now reduced the data, it fits into the limit now. I am still working on the final snippet, which will include the solver and therefore does not need the big solution data.

By on 1/23/2018 1:55 AM ()

This snippet does not have code service working because of max size for websocket messages is limited at 200000B currently, while this has length 229399. (Compile request does a form submit, so not limited by the websocket message limit) We are in the process of investigating try.ws to improve performance, something is causing a CPU leak in F# type checking.

I have found the problem with using [<assembly: JavaScript>] is that it also compiles the value of Snippet.IndexHtml, a hidden string value generated from the HTML markup so that it can be passed to the templating type provider. And this string literal causes some problems when the result of compile is inserted in the iframe (the stange thing is that the same line in the result of compile works when pasted into JS console in both Chrome+Firefox...)

There is a way to annotate just a single file, with

1
2

[<assembly: JavaScript "code.fs">]
do()

I have tested that this works. ("code.fs" is how try.websharper names the virtual file containing the snippet code)

By on 1/10/2018 7:59 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper