Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 30 04:27
    cookyzed starred dotnet-websharper/core
  • Jan 28 20:39
    kirchnergo starred dotnet-websharper/core
  • Jan 23 16:49
    artemprokopov starred dotnet-websharper/core
  • Jan 15 11:59

    Tarmil on 4.5.6.320

    (compare)

  • Jan 15 11:59

    Tarmil on master

    Version 4.5.6.320 (compare)

  • Jan 03 18:44
    AndreiDegtiarev closed #1036
  • Jan 03 18:44
    AndreiDegtiarev commented #1036
  • Jan 03 11:46
    AndreiDegtiarev commented #1036
  • Jan 03 09:20
    Jand42 labeled #1038
  • Jan 03 09:20
    Jand42 commented #1038
  • Jan 03 08:57
    Jand42 commented #1037
  • Jan 03 08:50
    Jand42 commented #1036
  • Jan 03 08:50
    Jand42 commented #1036
  • Jan 03 08:49
    Jand42 commented #1036
  • Jan 03 08:48
    Jand42 commented #1036
  • Jan 01 00:13
    jpalmer opened #1038
  • Dec 29 2018 16:29
    MrJohnCoder starred dotnet-websharper/core
  • Dec 28 2018 15:27
    lulzzz starred dotnet-websharper/core
  • Dec 27 2018 20:00
    alexander-demidov starred dotnet-websharper/core
  • Dec 23 2018 13:06
    AndreiDegtiarev opened #1037
Loïc Denuzière
@Tarmil
you mean dragging an email attachment from outlook to your app? yeah that should give a standard file drop event
giuliohome
@giuliohome
Awesome! Yeah, with the files attached to the email automatically drag&dropped, that's what I mean. I read somewhere on internet/github that it should be supported by chrome (and ms edge on win10), the old browser problem being that the attached files are "virtual", not saved on disk.. however I've no direct experience of this topic yet, it's just something I could be working on in a (near) future. Thanks a lot for your above reply
Thank both of you for the replies
giuliohome
@giuliohome
Great! I will look at the library samples later and I will likely integrate it into my project in the next months, I guess.
To be clear, the point is that they don't want to drag from win explorer (because they have to save the attachments before otherwise) but directly from outlook..
Alexandre Péret
@AlexPeret
@giuliohome "the old browser problem being that the attached files are "virtual", not saved on disk.." yes, that might be a problem. I believe it can upload from a hyperlink, but never tested. Also, Outlook might not be providing such link, as well.
Alexandre Péret
@AlexPeret

hi!

I've published a project containing a few widgets and samples using WebSharper, put together while learning the framework. Hopefully, it might help new people starting on WebSharper.

Also, the WebSharper team might find it interesting to see how a newcomer is using their framework.

Icu Testers
@IcuTest_twitter
@AlexPeret sweet!! :thumbsup: :thumbsup:
Alexandre Péret
@AlexPeret
hi! is there a way to observe a Var without a View?
Loïc Denuzière
@Tarmil
You can get the current value with .Value, but to observe dynamically you need to use a View
if all you want is to call a callback though, you can then pass the View to View.Sink or View.RemovableSink
Alexandre Péret
@AlexPeret
@Tarmil thanks Loïc! this was exactly what I was looking for.
by the way, seems the websharper.com site has an expired certificate and it is not loading on Firefox.
giuliohome
@giuliohome

Is there a way to transform a Moment date (see below) back to a DateTime?

Moment(log.AsofDate).ToUtc().Add(1,"d")

I'm using such date to set a Var

let NoLogSelected = None : System.DateTime option
let selectedLogVar = Var.Create NoLogSelected
giuliohome
@giuliohome
Maybe this...
Moment(log.AsofDate).ToUtc().ValueOf() :> obj :?> System.DateTime
Alexandre Péret
@AlexPeret
@giuliohome or maybe it might work too:
Moment(log.AsofDate).ToUtc().ToDate().Self
but I never used this lib before. Just guessing.
giuliohome
@giuliohome
@AlexPeret thank you, I try it now, because my above code is wrong
giuliohome
@giuliohome
nope...
it compiles fine, but I'm not getting the date I would expect
giuliohome
@giuliohome
I'm testing this right now :-/
let asof_date = Moment(log.AsofDate).ToUtc().Add(1,"d")
System.DateTime(asof_date.Year(), asof_date.Month() + 1, asof_date.Date())`
Alexandre Péret
@AlexPeret

I've ran a quit test using the following:

        Moment.Locale("br")
        let now = new Moment()

        let dotnetDateTime = now.ToUtc().ToDate().Self
        let jsDate = now.ToUtc().ToDate().Self
        Console.Log (dotnetDateTime.ToShortDateString())
        Console.Log (jsDate.ToShortDateString())

        let dotnetDateTimePlus1 = dotnetDateTime.AddDays(1.)
        let jsDatePlus1 = now.Add(1,"d").ToUtc().ToDate().Self
        Console.Log (dotnetDateTimePlus1.ToShortDateString())
        Console.Log (jsDatePlus1.ToShortDateString())

It seens to work. Not sure if it applies to your use case. This is the output:

17/09/2019
17/09/2019
18/09/2019
18/09/2019
Alexandre Péret
@AlexPeret
is log.AsofDate comming from the server?
giuliohome
@giuliohome
My above code is working fine IMO. What you should try is changing the time zone in your win os from say europe to usa and check that the date remains the same: the only way I've found is the code I've posted above
log.AsofDate is coming from the server as datetime (not utc)
but the issue is all client side IMO
Alexandre Péret
@AlexPeret
I had some trouble using datetime coming from server and back to it before and I wrote this article to document my findings. Maybe it will help you. Also, you can find the code at that sample project.
giuliohome
@giuliohome
You are not testing the case when the function for the utc time should return a different date than the date of the local time, and I suspect this is the root of my issue.
giuliohome
@giuliohome

I'm testing this right now :-/

let asof_date = Moment(log.AsofDate).ToUtc().Add(1,"d")
System.DateTime(asof_date.Year(), asof_date.Month() + 1, asof_date.Date())`

This is the code I've moved into Production now, I think it is returning a fixed datetime, based on utc, irrespective of the local time zone. While Moment toDate is based on the local timezone (confirmed here? moment/moment-timezone#309)
In conclusion I hope the code I've written above is right, but since is quite admittedly contrived, please ping me if you find a possible bug, thank you again

Alexandre Péret
@AlexPeret
I will test it later. My hyphotesis is that changing the UICulture on the server request, based on the client's locale and while using the ToLocalTime() function from DateTime might fix it
giuliohome
@giuliohome
I believe that what you say is correct even without trying it, but I'm trying not to change the UICulture (is it the only option? why can't we manage different uicultures for something like a datetime type that is supposed to do that, or what am I missing?) and, just to be clear, here is my scenario. Assume that the server is returning 17 September at 01:00 AM European local time. When an American timezone browser receives such date from the server, it reads it as 16 September (let's say 06:00 PM). What I'm doing is a function client side that trasforms the two different local dates on the two browsers/clients (conceptually the same date UTC) into a new datetime that must be equal (in terms of the date part, i.e. let's say 17 September) for both clients.. and all this contrived code exactly because the remoting server seems not able to manage the different local timezone - representing the same date - automatically (as I would have expected initially... or am I still wrong now?)
Alexandre Péret
@AlexPeret

@giuliohome If I understand correctly, you want to show the same datetime on different timezones, but using the local format.

My understanding is that WebSharper converts the DateTime using the ISO 8601 which has the timezone offset in it.

If you make a RPC call and sniff the request, you can see that it is sending the datetime as a number that is probably used by the Date (javascript) to convert it back to datetime.

Now, converting the date to UTC or Local on the server, won't make any difference, as the same value will be sent to the browser, which converts it back to datetime using the offset.

So, a possible solution is to drop the datetime Offset on the server or send it as string, what might not be useful.

I've tried a few things without success, like dropping the timezone offset:

    // at the Rpc function
    DateTimeOffset(
        DateTime.SpecifyKind(DateTime.Now, DateTimeKind.Unspecified),
        TimeSpan.Zero).DateTime

no change.

Also tried the DateTimeFormat at the Rpc function:

    //[<DateTimeFormat @"yyyy-MM-dd\THH:mm:ss\Z">]
    [<DateTimeFormat @"yyyy-MM-dd\THH:mm:ss">] // without the Z. Is it correct?
    [<Rpc>]
    let TestDate () = 
        async {
            return DateTime.Now
        }

or

    type TestRecord = {
        [<DateTimeFormat @"yyyy-MM-dd\THH:mm:ss">] // without the Z
        DateNoTZ: DateTime
    }

    [<Rpc>]
    let TestDateWithRecord () = 
        async {
            return { DateNoTZ = DateTime.Now }
        }

but none of them worked. So, I run out of ideas.

giuliohome
@giuliohome
Thank you for your time. I should have provided a sort of minimum reproducible example but I was in a hurry to finish my work activity. Now I'm at home, where I hope to quickly clarify my ideas and come back here in a few minutes...
giuliohome
@giuliohome

Let's look at this code of WebSharper.Web/ClientSideJson.fs.
Please, the experts correct me if I'm wrong but I guess this is the part that reads/interprets, cient side, the result of the server

    let DecodeDateTime() =
        ()
        fun () (x: obj) ->
            if JS.HasOwnProperty x "d" then
                Date(x?d: string).Self
            else 
                Date(x :?> string).Self

    let DecodeDateTimeOffset() =
        ()
        fun () (x: obj) ->
            if JS.HasOwnProperty x "d" then
                System.DateTimeOffset(Date(x?d: string).Self, System.TimeSpan.FromMinutes x?o)
            else 
                System.DateTimeOffset(Date(x :?> string).Self, System.TimeSpan.Zero)

Now there is a subtle point that is not convincing me (assuming that I'm not looking at the wrong part of the code, at first, lol)

giuliohome
@giuliohome
The point is that a datetime should not be decoded as a local date but as a utc date, so my wild guess is that the datetime part of the decoding stuff should be "fixed" (again, I'm just a beginner with W# so pardon if wrong) to.. maybe...
    let DecodeDateTime() =
        ()
        fun () (x: obj) ->
            if JS.HasOwnProperty x "d" then
                System.DateTimeOffset(Date(x?d: string).Self, System.TimeSpan.Zero)
            else 
                System.DateTimeOffset(Date(x :?> string).Self, System.TimeSpan.Zero)
giuliohome
@giuliohome
Well, my proposal is wrong because it returns the wrong type and, more importantly, because it still uses the same (JavaScript right) Date... So, ok, honestly I'm not able to suggest a valid alternative and I already have a patch for my code in my repo... I'd say we can close this topic for now
giuliohome
@giuliohome
What I was really missing was a ToUTC() function in the DateTime implementation for the JavaScript Client. I resorted to MomentJS to get the UTC, that's it.
Loïc Denuzière
@Tarmil
actually ClientSideJson is not currently used for RPC
it's used for Json.Serialize
there's a proposal to switch to it dotnet-websharper/core#930
giuliohome
@giuliohome

thank you @Tarmil
Good to know. But in any case I think the final javascript is something that reads a utc string and interprets it as a local date.

var json2 = '"2019-09-19T00:00:00Z"'
var back2 = JSON.parse(json2)
var date2 = new Date(back2)

So if I set my time zone as Central USA (utc - 6), my

date2.getDate()

returns 18.

Nothing especially wrong with it, I only need a ToUTC, which is not available in the current W# DateTime but it is possible via moment.js as i've already said. So far so good, thank you again for the support and the clarification about W# core code.

giuliohome
@giuliohome
btw I've discovered that there is a JS getUTCDate()
giuliohome
@giuliohome
Snippet tested with USA and Europe time zone, the UTC date remains fixed as expected, awesome .
relevant code is (sorry I forked an existing C# one)
var nowJs = new WebSharper.JavaScript.Date("2019-09-19T00:00:00Z");
var utcDate = new DateTime(nowJs.GetUTCFullYear(), nowJs.GetUTCMonth() + 1, nowJs.GetUTCDate());
Alexandre Péret
@AlexPeret

@giuliohome hi! about this line
"The point is that a datetime should not be decoded as a local date but as a utc date"

While testing it, I've notice the RPC call is returning the same value for Local and UTC dates format (as a number).

My understanding is this date value (the number mentioned above) is the UTC one, as the Local time always carries the offset, therefore being the same thing.

Once the date is deserialized at the client, it will format such date according to its locale.

I believe it is the correct behavior, but it might not apply to scenarios like your use case.

If my assumptions are correct, you should drop the offset at the RPC function, so the returned date would behave like a UTC (discounting the offset). The problem is the RPC attribute seems to restore back the offset. Probaby, it is something related to Json serialization and DateTimeKind.

giuliohome
@giuliohome
lol ... I wrote a lot of lines after that one ...
I'm really convinced that I should do what I have done :)
Alexandre Péret
@AlexPeret
sure. I just referenced that line to make sure my point, which is the problem is on the server side and not on that client, if I'm not missing anything. But I probably don't have the whole picture in my mind. Glad you solved it.
giuliohome
@giuliohome
My problem is on client not on server. Me too on the other side, I don't have the whole picture of what you are saying is the problem on server, which must be different from my case anyway.
Icu Testers
@IcuTest_twitter
Is ngen.exe still applicable for wsfc.exe? My compiles are getting slow :frowning: