Add time-traveling debugger

[forki]

http://elm-lang.org/blog/the-perfect-bug-report

I think I want to give it a shot.

/cc @et1975 @alfonsogarciacaro

[alfonsogarciacaro]

I think @mastoj is already working on something similar for fable-arch.

[forki]

Cool maybe should join forces. @mastoj Where can I find the current state of the art?

[mastoj]

Check the plugin sample of fable-arch.
On Fri, 18 Nov 2016 at 13:38, Steffen Forkmann notifications@github.com
wrote:

Cool maybe should join forces. @mastoj https://github.com/mastoj Where
can I find the current state of the art?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAemsMpuWS8L_jDW_XZ7zJQAu6vw3PfXks5q_ZxLgaJpZM4K2bdM
.

[forki]

do you hava a link?

[mastoj]

http://fable.io/fable-arch/samples/plugin/index.html

On Fri, 18 Nov 2016 at 14:36, Steffen Forkmann notifications@github.com
wrote:

do you hava a link?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAemsOVdZk1333clAwId9DQZT9-3eOInks5q_anHgaJpZM4K2bdM
.

[et1975]

I was thinking to check Redux tools/debugger needs and see if there could be a layer implemented in elmish to make it compatible with that.
If not, see about porting Elm implementation, if it's in Elm (not JS) it is very straight forward. Not sure Elm 0.17 has got the debugger going though.

[forki]

cool. so where can I read about this thingy? I don't really understand how to use it. Also are you planning to do export/import?

[forki]

@et AFAIK debugger is in 0.18

[mastoj]

@forki , I've been thinking about export import, but haven't got the time to do it. Also, I haven't done much with documentation. Basically it's just another app that is running side by side with the applications that listens for all events. I've opened up my abstractions to replay events so the devtools can feed events back to the applications that is being monitored.

[et1975]

Found the Elm debugger here: https://github.com/elm-lang/virtual-dom/blob/master/src/VirtualDom/Debug.elm

Conceptually, the Elm debugger is a program that wraps your program, just like my navigation port does.

It's not much use for elmish as it is however: Since it has visual elements, it has to be split into core, react (and/or chrome debugger extensions) and native parts, to accommodate both browser- and RN- targeting apps. Following on that thought, native already has a way to ship logs and the exported history would be a good fit that.

[zalmoxisus]

@et1975,

I was thinking to check Redux tools/debugger needs and see if there could be a layer implemented in elmish to make it compatible with that.

There's an integration with Redux DevTools Extension: https://twitter.com/FableCompiler/status/772745186287947776

Redux DevTools Extension can be integrated easily with any architecture, if you need more details on this, let me know.

[alfonsogarciacaro]

Fantastic! I love Redux DevTools Extension and actually it's already possible to use it with Fable but being able to use it natively with fable-elmish and fable-arch would be just so awesome. Thanks a lot for your help, @zalmoxisus!

[zalmoxisus]

@alfonsogarciacaro, you can send messages to it from anywhere via sockets, like remote-redux-devtools does. Here's a simpler js lib you can adopt. It uses socketcluster-client under the hood, which has native drivers for ios and android as well.

[et1975]

Looks promising, thanks Mihail!

[et1975]

@forki Seems the sockets client would be the way to go for hooking up Native debugging. It could go into elmish since it doesn't have any React dependencies. If you want to take on this, here's how I see it: a debugger Program module that hooks up both subscribe (for the debugger events), and update to forward updates to the extension.
The browser nav impl has to be changed as well, since it won't be a root any longer and the final run needs to be outside... I can take on that.

[forki]

Yeah currently I took up another challenge. So I guess this is out of scope
for me right now.

Am 22.11.2016 15:50 schrieb "Eugene Tolmachev" notifications@github.com:

@forki https://github.com/forki Seems the sockets client would be the way
to go for hooking up Native debugging. It could go into elmish since it
doesn't have any React dependencies. If you want to take on this, here's
how I see it: a debugger Program module that hooks up both subscribe (for
the debugger events), and update to forward updates to the extension.
The browser nav impl has to be changed as well, since it won't be a root
any longer and the final run needs to be outside... I can take on that.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNJAUWnmbI7lWeAFMveJTgb7uQmfIks5rAwE6gaJpZM4K2bdM
.

[et1975]

@zalmoxisus I wonder if I could ask your help investigating the weird behavior I'm seeing.
The counter sample in my fork has been updated to use the remotedevtools lib and it used to work flawlessly, but since upgrading the transpiler and the dependencies and doing a clean build it's completely borked.

I'm suspecting that either my code or fable is doing something wrong, but I can't tell what.

Symptoms, using the Chrome extension:

• sometimes on init I get DISPATCH with no state sent to me
• the actions don't appear in history, although they make it to the extension, as evidenced by the ability to time-travel back.
• for every one action sent, there appear to be multiple entries recorded (observing the time-travel again)
• fiddling with the the extension, reloading the app, etc sometimes breaks extension - history section is not shown at all and there appears to be no way to bring it back, short of reopening the window.

using the local server and a stand-alone monitor:

• for every one action sent, there appear to be multiple update entries recorded.
• all the duplicates added appear to share the same state.

The counter sample has the transpiled F# checked in (in out subfolder), so maybe you could tell just by looking. If you decide to give it a spin, you should be able to run with just yarn install in the samples/react and yarn start in the samples/react/counter (it will start a local webpack dev server).

Thanks in advance!

[zalmoxisus]

Hey @et1975,

At first, when trying to open the example, for some reason, I get null passed to window.__REDUX_DEVTOOLS_EXTENSION__.connect, so it just throws. We're setting {} as the default value of the config here, but it works only when nothing is passed as the argument (or the argument is undefined). We could handle null too if it is necessary

sometimes on init I get DISPATCH with no state sent to me

I guess you're getting START not DISPATCH, unless you clicked to persist the state. That's my fault. I don't remember why I removed checking for DISPATCH here. Anyway DISPATCH not always contains the state, for example when canceling actions, the state should be computed on the client side.

I fixed it in zalmoxisus/remotedev@7650a40. Updating to remotedev@0.2.4 should help. But you should call extractState(msg), instead of extractState()(msg) like now in

            var sub = function sub(dispatch) {
                connection.subscribe(function (msg) {
                    var state = __webpack_require__.i(__WEBPACK_IMPORTED_MODULE_5_remotedev__["extractState"])()(msg);
                    program.setState(state)(dispatch);
                });
            };

BTW, few days ago, I wrote a draft of the API, where you can find more details of the types beside DISPATCH.

the actions don't appear in history, although they make it to the extension, as evidenced by the ability to time-travel back.

You're sending {"Case":"Increment","Fields":[]} as the action. So, because there's no type key, nothing is shown. It should be either a string (which will be interpreted as action type) or an action object which should contain type as the key.

for every one action sent, there appear to be multiple entries recorded (observing the time-travel again)

I don't seem to reproduce that. Just added the type key to that object and am getting actions one by one. There's another problem - the state I get for the actions is not actual, but the state before the dispatching occurs.

fiddling with the the extension, reloading the app, etc sometimes breaks extension - history section is not shown at all and there appears to be no way to bring it back, short of reopening the window.

Could you please check if in this case the extension's script was loaded after you try to call it (check if window.__REDUX_DEVTOOLS_EXTENSION__ is available from within the code).

using the local server and a stand-alone monitor: for every one action sent, there appear to be multiple update entries recorded, all the duplicates added appear to share the same state.

That's a sign that you're subscribing to the channel twice. Maybe that API draft could help.

[et1975]

Thank you so much for looking into this!

I get null passed to window.REDUX_DEVTOOLS_EXTENSION.connect, so it just throws.

I went back to the clean repo after submitting the comment to make sure you are able to reproduce and sure enough I hadn't published the version I was discussing. I guess you pulled the repo before I was able to push the update, sorry about that!

because there's no type key, nothing is shown.

This part confuses me. When everything worked, I had exactly the same action obj sent. It didn't show up as an update, but it did show up as a row with the timestamp. Not anymore. I saw your lib augmenting the action with the type, but I guess that happens only for a "remote" case, not "viaExtension"?

I don't seem to reproduce that.

That's my bad, I mentioned only the counter example but that's something I observed in react/todomvc and react-native/counter. I thought it might give some insight into "nothing is shown" problem, but your other comment about subscribing to channel twice makes it unlikely.

That's a sign that you're subscribing to the channel twice.

I might have a problem somewhere in the initialization, but wouldn't it playback multiple times as opposed to show multiple history entries?

Here's what the extension looks like, once I reload it:

As you can see in the console output at the bottom, the window.__REDUX_DEVTOOLS_EXTENSION__ is there, but history and timetravel controls have disappeared.

[zalmoxisus]

This part confuses me. When everything worked, I had exactly the same action obj sent. It didn't show up as an update, but it did show up as a row with the timestamp.

Yes, it's only in remotedev, not in the extension. Probably it's worth having a default type like this, though we could do even better and add the ability to specify the type key in the config like window.__REDUX_DEVTOOLS_EXTENSION__.connect({ actionTypeKey: 'Case' }), so for {"Case":"Increment","Fields":[]} it would show Increment.

I might have a problem somewhere in the initialization, but wouldn't it playback multiple times as opposed to show multiple history entries?

I was wrong here, it's about emitting not subscribing. Hard to say what could be the reason without a repro.

Here's what the extension looks like, once I reload it...

Could you please provide some steps to reproduce? I tried to reload several time the app window and the extension window and still not getting that issue. You can press Cmd+Alt+I on the extension's window, to see the exception, but it will not help much as the problem should be in the background script.

[et1975]

we could do even better and add the ability to specify the type key in the config

that would be pretty sweet, although if I may offer a "functional" twist, define it something like:
.connect({getType: (a) => a.Case})

Could you please provide some steps to reproduce?

Something like:

• start the SPA
• open dev console
• open the extension
• increment/decrement, try to step back
• close the extension
• open the extension

At this point it's messed up and won't work until I reopen the SPA tab.

[zalmoxisus]

Could you please try to update the extension? I just published 2.12.1 to Chrome Store, which also includes getActionType parameter.

Also I had to change in fable-elmish-debugger/debugger.js:

        var subscribe = function subscribe(model) {
            var sub = function sub(dispatch) {
                connection.subscribe(function (msg) {
-                    var state = extractState()(msg);
+                    var state = extractState(msg);
-                    program.setState(state)(dispatch);
+                    if (typeof state !== 'undefined') program.setState(state)(dispatch);
                });
            };

            return CmdModule.batch(ofArray([ofArray([sub]), program.subscribe(model)]));
        };

[et1975]

@zalmoxisus Thank you, works flawlessly via the extension! I'll try RN stuff in a bit...

[zalmoxisus]

@et1975, glad to know. I've just added that function also in remotedev@0.2.5. Will try to unify them after 3.0 release of the extension.

[et1975]

@zalmoxisus works with Native and local server too! Thanks, Misha!

[et1975]

And... it is out!

fable-elmish@0.8.0
fable-elmish-react@0.8.0
fable-elmish-debugger@0.1.0

samples/react/counter and samples/react-native/counter have been updated to use the debugger.

[et1975]

There's a known issue, specifically about the counter samples - it uses a simple int for the model, and it doesn't roundtrip properly when the value is 0. I don't expect anyone to use such a model in real life, so I'm not going to bother fixing it. Closing!