Debug not as verbose when enabling via method

[aulneau]

I'm working with redux-bundler and next.js (ssr react), and when trying to enable debug mode by doing something along the lines of

componentDidMount(){
    localStorage.debug = true
}

Redux bundler doesn't catch it and it never turns on. However when I enable it via the exposed function, it does turn it on but I no longer can see the selectors or reactors.

This is what I see:

vs the sample project (and other non-ssr apps I've used redux-bundler with)

[HenrikJoreteg]

Ah, interesting. Should be a fairly simple fix. I think I know what is happening. Thanks for reporting this.

[HenrikJoreteg]

@aulneau this is a bit trickier than I originally thought. The thing is, the determination of whether or not it is in debug mode really only happens once this is because init is only fired on startup: https://github.com/HenrikJoreteg/redux-bundler/blob/master/src/bundles/debug.js#L24

The determination originally happens here: https://github.com/HenrikJoreteg/redux-bundler/blob/master/src/utils.js#L1-L5

Would you mind explaining a bit more what you're trying to do? My idea behind how this feature would work is you'd set localStorage.debug = true using the devtools in your browser, not from within your application code, then you'd refresh. That way it's always there if you want it, and you can ship it to production, but only turn it on when you need it.

Regardless, it may make sense to change it so that the code that currently runs in that init block instead would run when you call doEnableDebug().

Anyway, I'd love to better understand what you're trying to do, thanks!

[aulneau]

ah okay so yeah, I think this works great in not ssr environments, but it seems to break with anything server side. When I enable the flag, it never registers. Whereas if I enable it via:

  componentDidMount() {
    if (!this.props.store.selectIsDebug()) {
      this.props.store.doEnableDebug();
    }
  }

It enables it, but in the limited version I've mentioned before.

One solution would be to check for a cookie with the debug bool set to true, or another non-window object that could be read in contexts outside of the client.

Regardless, it may make sense to change it so that the code that currently runs in that init block instead would run when you call doEnableDebug().

I think that makes sense, too!

[HenrikJoreteg]

Ah, I see. So you want these log messages in your terminal in node while debugging SSR, is that right?

…

On Tue, May 22, 2018, 16:12 Thomas Osmonson ***@***.***> wrote: ah okay so yeah, I think this works great in not ssr environments, but it seems to break with anything server side. When I enable the flag, it never registers. Whereas if I enable it via: componentDidMount() { if (!this.props.store.selectIsDebug()) { this.props.store.doEnableDebug(); } } It enables it, but in the limited version I've mentioned before. One solution would be to check for a cookie with the debug bool set to true, or another non-window object that could be read in contexts outside of the client. Regardless, it may make sense to change it so that the code that currently runs in that init block instead would run when you call doEnableDebug(). I think that makes sense, too! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEJVf2n8f19i8SHmCLxlFmUfZzWQCSqks5t1JtQgaJpZM4UDYcH> .

[aulneau]

@HenrikJoreteg No I'm fine with it only in the client personally -- it seems like the issue might be that the init function does not fire on the server, and then the client never picks it up

[HenrikJoreteg]

The only thing that matters in terms of seeing those messages is whether or not local storage debug is set to a true value at the point the app first boots up so if you set it using Chrome Dev tools and refresh the page you should always see all the messages. Is that not happening? If you set it as part of component did mount it's already too late.

…

On Tue, May 22, 2018, 16:36 Thomas Osmonson ***@***.***> wrote: @HenrikJoreteg <https://github.com/HenrikJoreteg> No I'm fine with it only in the client personally -- it seems like the issue might be that the init function does not fire on the server, and then the client never picks it up — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEJVfTRTbGYQypnIY1qtTI4V_fZLx1Oks5t1KD5gaJpZM4UDYcH> .

[HenrikJoreteg]

Oh I bet I know what's going on. Are you transferring all of the state from the server side to the client somehow as part of a bootstrap data or something? If so the client might be getting an initial state of debug false from the server side render. In that case you would just want to remove any initial State for the debug bundle from the data that is bootstrapped and sent to the client.

…

On Tue, May 22, 2018, 16:50 Henrik Joreteg ***@***.***> wrote: The only thing that matters in terms of seeing those messages is whether or not local storage debug is set to a true value at the point the app first boots up so if you set it using Chrome Dev tools and refresh the page you should always see all the messages. Is that not happening? If you set it as part of component did mount it's already too late. On Tue, May 22, 2018, 16:36 Thomas Osmonson ***@***.***> wrote: > @HenrikJoreteg <https://github.com/HenrikJoreteg> No I'm fine with it > only in the client personally -- it seems like the issue might be that the > init function does not fire on the server, and then the client never picks > it up > > — > You are receiving this because you were mentioned. > > > Reply to this email directly, view it on GitHub > <#24 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAEJVfTRTbGYQypnIY1qtTI4V_fZLx1Oks5t1KD5gaJpZM4UDYcH> > . >

[aulneau]

Ah yes exactly. I'm fetching data on the server and passing it through to the client. I'm not sure immediately how I would blacklist the debug data from being initialized on the server with everything else. Do you have any suggestions?

[HenrikJoreteg]

I suppose you could just make sure it's set to true on the server side while you're developing.

…

On Wed, May 23, 2018, 09:57 Thomas Osmonson ***@***.***> wrote: Ah yes exactly. I'm fetching data on the server and passing it through to the client. I'm not sure immediately how I would blacklist the debug data from being initialized on the server with everything else. Do you have any suggestions? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEJVXfWeyCkkPcuKCCkUdvTPPQQs-nSks5t1ZTjgaJpZM4UDYcH> .

[HenrikJoreteg]

Quick update on this, so... i did SSR for a project recently, and when transferring state from server to client, you really don't want to include everything from every reducer. Because, for things like debug, and several other scenarios I found... you really want that to be determined in each environment where it runs. This way the server can have debug off and the client can have it on.

The usual approach for this state transfer is to send along all of store.getState()

What I ended up doing, that worked quite well, was creating a tiny bundle with a selector called selectSSRState that does this:

export default {
  name: 'ssrState',
  selectSSRState: state => ({
    reducer1ThatIwantToInclude: state.reducer1ThatIwantToInclude,
    otherReducer: state.otherReducer
  })
}

Then in your SSR function when getting state on the server, to transfer to the client, instead of store.getState() just use store.selectSSRState().

Just thought i'd post this here in case anyone came along and was wondering about this.

[HenrikJoreteg]

just published v25.0.0, it includes a fix for this, thanks! https://github.com/HenrikJoreteg/redux-bundler/blob/master/docs/misc/changelog.md#change-log