Port debugger support for Fable 1.x

[elmish]

Port debugger support for Fable 1.x

[et1975]

Nice tracking skills! Changed to Int32.Parse, and released fable-elmish-browser update.

[alfonsogarciacaro]

@johlrich No idea, sorry. Looks like a bug. It'd be very helpful if you could send the failing tests. TDD FTW! ..T standing both for types and tests ;)

[johlrich]

Hey just noticed this, how is this coming along? I actually have a branch with the serialization part working,

I can open a PR to show the wip if you wanted, I would have on Monday, but I had been doing the changes in another project's node_module folder instead of the actual fork by mistake and need to move the code over. It's been a busy few days and forgot to open a ticket, sorry about that!

[et1975]

No worries, send it in, look forward to seeing it!

[johlrich]

Just added #58 with some comments for additional info / discussion.

[et1975]

While we're at it, we should probably change the withConsoleTrace as well... new DUs are unreadable w/o reflection.

[et1975]

@johlrich so... I just released it as @0.9.0-beta-6 and tested it on navigation sample: it doesn't work when it comes to stepping through the history - at a glance it needs convert reflected DU case names back to DU tags.

[johlrich]

OK, taking a look using the sample. Finally learned how to get webpack / npm link playing nice so it'll be easier for me to check changes in the future w/ samples before a PR as well

[johlrich]

@et1975 So it looks like there is an issue with inflateUnion in fable-core with the | Blog of int case. If you want to see it working at least a bit, try having a history that click home / searches a zip code and you can jump around those correctly.

/cc @alfonsogarciacaro I'll write a failing test upstream in fable now, but just an FYI if you know why deserializing a union case of int would blow up.

[johlrich]

@et1975 I can't reproduce this in fable directly and have gotten a bit stuck on with the triage. A little more detail / update:

When the type was being deserialized there was a string number in the object payload being inflated. I thought this was something in the redux devtools, but when I put a breakpoint in elmish-debugger before it sends the model during update, the underlying JS has a string for the data instead of a number type. This points to something on the application's side doing this. When I created some tests in QuickTest.fsx, I could see the data being a number properly. This is where I got confused.

To see if you're seeing what I am, try using the devtools w/ the navigation demo and hit set a breakpoint in the update fn. In the JS side you should see model.page.data as a string

[johlrich]

@et1975 Whew! Finally got to the bottom of this. So the problem is with how we're composing int >> Ok in https://github.com/fable-compiler/fable-elmish/blob/master/src/elmish-browser/parser.fs#L80

I'm not sure if the bug is with the int or >>, but that combination causes the Result union's JS object's data field to be given data of type string instead of number. I created fable-compiler/Fable#798 to track.

As a workaround, we could change int to System.Int32.Parse or just wait for a fix for the issue.