Back to Questions
635
views6
comments
Counter stub example in docs doesn't work
websharperjavascriptbug

https://developers.websharper.com/docs/v4.1/fs/bindings

(Using VS 2017 with WebSharper version 4.1.0.171)

The counter function works fine as expected when called from WebSharper, but constructing the Counter class fails. On examining the created code, it appears that the call let c = new Counter()

translates into

1

V = {}

rather than

1

V = new counter()

as expected. So a subsequent call to

1

c.Next ()

causes a JavaScript exception (no method next.)

Is this a bug, or am I doing something silly?

And BTW, is this the correct place to report such things? And is there any way to get WebSharper to produce non-minified code from my project?

.

On the last question: you can turn off dead code elimination by having <WebSharperDeadCodeElimination>False</WebSharperDeadCodeElimination> in your project file for bundle (Single Page Application) project. It still concatenates all available code into a single .js output (having a minified version too, which is linked in the static index.html by default).

By on 1/8/2018 1:27 AM ()

Thanks for this info. I should have been more specific. I'm using the suave client-server template in VS, and unlike with the asp.net one, there doesn't appear to be somewhere to say

<compilation debug="true" targetFramework="4.0" />

so that the non-minified version of the .js file is sent to the browser.

By on 1/8/2018 2:19 AM ()

As Suave does not use a web.config, you can use the overload of WebSharperAdapter.ToWebPart that takes a configuration object. So instead of

1

(WebSharperAdapter.ToWebPart(Main, RootDirectory = @"../.."))

use

1
2
3
4
5
6
7

(WebSharperAdapter.ToWebPart(
    WebSharper.Owin.WebSharperOptions(
        Sitelet = Some Main, 
        Debug = true, // this makes WebSharper to use non-minimized .js links
        ServerRootDirectory = System.IO.DirectoryInfo(@"../..").FullName)
    )
)

The root path needs some conversions to get canonical full path in this case, which should be fixed soon, see https://github.com/dotnet-websharper/owin/issues/19

By on 1/9/2018 6:52 AM ()

Hello, thanks for the report!

These forums or either the WebSharper repo is a good place for issue reports. The documentation repo is also a good place for questions and issues about the documentation.

I have tested the Stub behavior, and it works as intended if a Name attribute is also present on the Counter class:

1
2
3

    [<Stub; Name "Counter">]
    type Counter() =
        // ...

(You can also have something like Name "X.Y.Z" if a JavaScript class or function is not in the global scope.)

I have created a ticket now for this here https://github.com/dotnet-websharper/websharper/issues/879, will be resolved soon one way or another then I will report back here too.

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

Thanks. Tested this and confirm now works as expected.

By on 1/8/2018 2:14 AM ()

We have fixed Stub attribute to work as is documented (and was behaving in WebSharper 3.x). This is now released in WebSharper 4.1.1.

By on 1/9/2018 6:14 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