Turbolinks support

[t2]

With turbolinks, the gritter notification shows on every page. Have you tested this with turbolinks?

[dmtaub]

Has anyone else figured this out? I don't know enough about where gritter is storing the notifications, but there should be a way to clear it from the session or storage after the notification appears...

[dmtaub]

actually, it looks like in my case, it may be related to the jquery-turbolinks gem which indiscriminately binds those events bound to document-onload to page:load
My plan is to remove that gem, and bind what I need to run when turbolinks loads a page to page:load manually.

Another potential way to address would be to have the following code run before the new gritter messages are added:

$._data(document,'events')['page:load']=[]

as long as there is nothing else important in page:load, of course :)

[h55nick]

This has become a problem for me as well. Are there any solutions to get gritter working with turbo links?

[dmtaub]

if I recall correctly, my solution was to remove an additional gem, jquery-turbolinks, and manually bind events to both onload and ready

-m(obile)Dan On Dec 26, 2013 5:57 PM, "Nick" notifications@github.com wrote:

This has become a problem for me as well. Are there any solutions to get gritter working with turbo links?

— Reply to this email directly or view it on GitHubhttps://github.com/RobinBrouwer/gritter/issues/33#issuecomment-31239363 .

[h55nick]

you mind sharing the code for the binding? I assume you've figured out where gritter is storing the notifications..

[dmtaub]

in coffeescript:

$ setupPlayListEditor $(document).on 'page:load', setupPlayListEditor

the code you want to run on startup would be put in the setupPlayListEditor. make sure you remove the jquery-turbolinks gem and replace all instances of $(document).onLoad(fx); or its shortcut $(fx); with the code listed

here it is in javascript

$(myStartupFunction); $(document).on('page:load',myStartupFunction);

On Thu, Dec 26, 2013 at 6:22 PM, Nick notifications@github.com wrote:

you mind sharing the code for the binding? I assume you've figured out where gritter is storing the notifications..

— Reply to this email directly or view it on GitHubhttps://github.com/RobinBrouwer/gritter/issues/33#issuecomment-31240069 .

[RobinBrouwer]

Can you please show me some code that's causing this issue? Where are you calling the gritter functions? I can't seem to replicate the problem.

[robertjwhitney]

Anybody got a good patch for this besides removing jquery-turbolinks?

[mbell697]

I'm having the same issue, I created a minimal example app here: https://github.com/mbell697/gritter-turbolinks

If you head to '/gritters' and click the Post action link you'll get a new notification added to the display list every time it's clicked rather than the list being cleared on each request.

My guess is that the client side message cache isn't getting cleared out on turbo-links requests, hooking the turblinks 'page:fetch' event and clearing it out would fix the issue. I did check that the session isn't getting multiple messages, session[:gflash] only has one message each request.

[mbell697]

I sorted this out. You need to use the nodom_wrap option on the gflash call in your layout, i.e. in your application layout you need <%= gflash nodom_wrap: true %>. If you're calling the add_gritter helper in js.erb views you need to add the nodom_wrap option to every one of those as well, I don't see any way to set that globally.

The core issue is that by default the generated js is wrapped in a document ready callback which the jquery-turbolinks gem calls on each turbolinks page:load event.

There are probably better ways to handle this than the nodom_wrap approach but it would require a bunch of changes to this gem, e.g. keeping a handle to each callback added and unregistering them in a page:fetch event callback.

[robertjwhitney]

@mbell697 ah! :thumbsup: ty

[madaarya]

you save my day @mbell697 !

[btazi]

Thanks @mbell697 !