*.js file not rendered when requesting from <a> HTML element

[Damián M. González]

Hello people, I'm wondering why this is not working. I have some plain
JavaScript wrote on mycontroller.js , works like a charm; I'm listening
to few events of the related view and works. I've been writing some
code, testing it manually refreshing the page in the browser and goes
ok.
The problem arise when I come to this view from another view. I have a
side-bar, when I click an <a> element it calls another action and render
another view. When I click the link which takes me to an action of
`mycontroller` controller the JavaScript work doesn't work, doesn't get
executed. Why is this?
I'm listening to the events by:

window.onload = function() {
document.getElementById('my_element').onclick = function() {
// do stuff...
}

// another listen...
}

I'm wondering if I should use another event more than window.onload ,
perhaps that doesn't get triggered when I come to this specific view
from an <a> HTML element. Do you have any clue about what's happening?
Thanks for your time, I appreciate it.

--
Posted via http://www.ruby-forum.com/.

[mike2r]

It's hard to say, you would need to follow it in a browser that has tools for that such as firebug in Firefox.  Chrome and Safari also have good developer tools.  My guess would be turbolinks.   If you are using Rails 4, turbolinks is installed by default.  Turbolinks regenerates the page's content without loading a new page.  Therefore, document.ready and window.onload aren't triggered.  You need to use one of turbolink's events, such as page:change.  See documentation at the following:

https://github.com/rails/turbolinks

If that's not it, I would need more information.  

[Damián M. González]

I will take a look to that link in my afternoon, interesting thing what
you say, thanks for the hand, I appreciate it.

[Jason Fleetwood-Boldt]

What exactly (please paste code examples) by "comes to this view from another view" ?

If the page is reloaded check to make sure your onload handler is re-attached correctly (you can do this with simple debugging or console statements inside of your onload function)

If you have some kind of ajax setup (like some of the default Rails stuff), then parts of the page might be getting replaced with new HTML content (Like your my_element). When that happens, the HTML is replaced and the new html elements do not have the click handler attached to them (and your onload is not re-run).

To keep things the way they are, try using jQuery 's on method (http://api.jquery.com/on/), which you should attached to a parent of the object that is getting replaced by ajax -- not the actual link itself.

Better yet, think about learning Backbone, Ember, or Angular. The way you are working with Javascript works OK in very tiny apps, but breaks down quickly in larger apps with a lot of client-side interactivity. Personally, I haven't written javascript in the style you are writing it (big, global class-bsaed targets that attach click handlers during the window's onload) since about 2009.

-Jason

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/6cc19be5-9f6c-4352-9614-314a50cda712%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Fleetwood-Boldt]

If you are using turbolinks you have to re-attach all your click handlers after the page content is replace, as discussed with detecting the page change event.

Like I said, in a small app you will get away with this but in a larger app you will drown in a nightmare of page change event binding and handler attachment bugs. This is why generally Javascript developers I know stay away from this style of coding and prefer a more robust think-client approach like the ones I mentioned. Obviously, detecting a change event may just be a small fix and learning a whole new way to write code is a bigger task.

On Jun 18, 2014, at 11:29 AM, mike2r <mr...@kalanitech.com> wrote:

[Damián M. González]

Jason Fb wrote in post #1150072:

> What exactly (please paste code examples) by "comes to this view from
> another view" ?

I'm in an HTML page, I click an anchor HTML element(<a>) which takes me
to another HTML page.

> If the page is reloaded check to make sure your onload handler is
> re-attached correctly (you can do this with simple debugging or console
> statements inside of your onload function)

It's not re-attaching. I'm thinking that turbolinks has something to
do.

> If you have some kind of ajax setup (like some of the default Rails
> stuff), then parts of the page might be getting replaced with new HTML
> content (Like your my_element). When that happens, the HTML is replaced
> and the new html elements do not have the click handler attached to them
> (and your onload is not re-run).

I don't know how can I check if this is happening?

> To keep things the way they are, try using jQuery 's on method
> (http://api.jquery.com/on/), which you should attached to a parent of
> the object that is getting replaced by ajax -- not the actual link
> itself.
>
> Better yet, think about learning Backbone, Ember, or Angular. The way
> you are working with Javascript works OK in very tiny apps, but breaks
> down quickly in larger apps with a lot of client-side interactivity.
> Personally, I haven't written javascript in the style you are writing it
> (big, global class-bsaed targets that attach click handlers during the
> window's onload) since about 2009.
>

> If you are using turbolinks you have to re-attach all your click
> handlers after the page content is replace, as discussed with detecting
> the page change event.

I'll take a look at how turbolinks work.

> Like I said, in a small app you will get away with this but in a larger
> app you will drown in a nightmare of page change event binding and
> handler attachment bugs. This is why generally Javascript developers I
> know stay away from this style of coding and prefer a more robust
> think-client approach like the ones I mentioned. Obviously, detecting a
> change event may just be a small fix and learning a whole new way to
> write code is a bigger task.

Thanks for the advices Jason, very helpfull.

[Jason Fleetwood-Boldt]

Try putting debugger or console.log("xyz") inside of your onload handler. If you don't see it break at the breakpoint or console output "xyz" when you click to a new page, then it isn't re-attaching.

I'm actually not the person to ask about using turbolinks (since I'm not a big fan), but it sounds like there's a way to detect the change event and re-call the function that makes the attachment. 

-Jason

-- 
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/51f725f6f4331357a22296162623c4a1%40ruby-forum.com.

[Damián M. González]

Yes, the issue was caused by turbolinks. What I did to fix it is very
simple, I've added the atribute 'data-no-turbolink' => true to the
link_to() which takes to the view with JS attached. Works like a charm,
thank you all for the help.

[Walter Lee Davis]

I wish there was some way to favorite these nuggets of gold in Apple Mail...

Thanks!

> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-ta...@googlegroups.com.
> To post to this group, send email to rubyonra...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/9477d832e64437f104bfed2fe6e7986a%40ruby-forum.com.