I want to create my own mouse tracker, like Clicktale and Crazy Egg. Tracking the mouse movements and scrolling shouldn’t be too hard. But what about all changes to the document (HTML, inputs and selects).
Is there an easy way to record all javascript actions on a site. So I can save the actions and later be able to repeat them when I want to replay the visitor’s actions?
Or somehow record all changes that are done to the document (saving the innerHTML everytime there is a change is probably not an option).
The recording must be related to time.
When the recording is done there will be an AJAX request that copies the page and insert the new Javascript in to it so it is possible to watch...
First of all I would like to say that even though the task you are describing sounds to be pretty easy, it is actually far more complex when you dig into it. I should know since I've been spending almost 3 years making stuff like this work and work well for my company Ehavior.
You can use the DOM mutation events to monitor changes to the DOM tree. I guess this will give you what you are asking for. You should be aware though, that the mutation events are only available in newer browsers.
Hope this is still helpful to you, even though your question is a little dated :-)
Related
Last year I tried to learn a bit React JS for making the project you can find here. I apologize for my rather vague / imprecise description below, but I'm by no means versed in this.
Basically, there is a single <svg> tag, which will contain a number of paths etc. as created by the user. The problem I have is that things become very slow the more paths are present. To my current understanding, this is due to the fact that the entire SVG DOM gets updated repeatedly upon user interactions that involve dragging the mouse or using the mouse wheel.
This holds true, particularly, for two user interactions:
a) Panning - all paths are being moved at the same time; I think one might circumvent this issue by taking a snapshot image first and moving that around instead. However, that's not a solution for the other user interaction, which is:
b) Expanding/collapsing paths - here, all paths are being modified in terms of coordinates of some of their points. That is, every path must be modified in a different way, but all of them must be modified at once, and this must happen repeatedly because it's a user interaction controlled with the mouse wheel where changes happen gradually and the user requires immediate visual feedback on these changes as they happen.
Particularly for b), I see no alternative that would involve a single transformation or something.
After extensive research last year, I came to the conclusion that choosing SVG to display and modify a lot of things dynamically on screen was a wrong decision in the first place, but I realized too late, so I gave up and have never touched it since. I'm pretty certain that there isn't any way to deal with the low performance that builds upon what I already have; I have no intention to start this project from scratch with a completely different approach. Also, the reason why I chose SVG was that it's easy to manipulate.
In summary, I'd basically like to get confirmation that there is no feasible way to rescue this project.
I am wondering about how async actions like animations work when you do actions like delete an item, and so came up with this sort of thought process and would like feedback to see if it makes sense from an industry best practice perspective.
There are two layers:
The reactive layer.
The rendering layer.
The reactive layer occurs instantly and can be done with traditional event dispatching.
This is where you create and delete data and it all happens instantaneously.
The state machine gets notified of these instant reactive changes.
Then the state machine "transitions". This process occurs over a period of time, assuming there are some async things that occur (animations, network requests, etc.). This is what people mean when they say "action queue".
Then the rendering layer pics up stuff off the action queue and renders it. This way there is sort of a delayed reaction to the underlying instant reactive layer.
My question is if the reactive layer needs to handle async as well. For example, deleting something.
Say an item is deleted, and you want to animate it out. There are a few ways to do this:
Queue up a delete action, then animate it out first. When animation is complete, then do the actual delete. If animation is interrupted (cancel the delete), then the delete is never performed.
Delete the item instantly (reactive layer). The animation layer keeps a reference to the item around, so can still do its animation even though from the global place it is deleted. If the animation is cancelled, then you would have to do an "undo" sort of thing which is more complex.
If (1) is the way to go, then there is no reactive layer, and everything is implemented with a sort of action queue in mind. This makes it harder to make reusable code because everything is tied to the action-queue idea.
If (2) is the way to go, then there are two copies of the data, the global copy, and the local copy, which is kept in sync asynchronously. This makes it easier to have reusable code but makes it more complicated to reason about.
Wondering if any of this makes sense, and if any of these approaches is better practice in the industry (or if there is an alternative I didn't address that makes more sense).
Put another way, there are two main ways to do it:
Eager: Delete it now, okay everyone we've deleted it, time to come back inside. And wait for everything to trinkle back in to call it "done".
Cautious: Announce "we are going to delete it", then wait til everything is done and comes back inside to actually do the delete.
Wondering how games and apps and such handle this sort of thing.
Update
After thinking about it a different way, maybe it would be more like the swaying of kelp in the ocean:
https://www.youtube.com/watch?v=gIeLCzR8EgA
By that I mean, there is a base layer that is immediate (does the create/delete), then there are some intermediate layers with copies of all the transactions that occurred (create/delete), that the rendering layer uses to animate create/delete. So the original data is always in sync, but the rendering layer uses a sort of older version of the data with a chain of all the changes taking place.
reactive layer -> transaction layer -> rendering layer.
Another option is flagging as delete, then only after animations are complete actually do the delete, but that seems hacky.
Update
Another version:
Reactive version
Always has the latest data. (a)
Rendering version
Has the last data (b), plus a chain of changes leading to (a).
As rendering completes, it applies the changes to (b), so eventually it is like (a).
from my experiece as Unity Game Developer the right decision is in the middle, as for the physics in game engine are approximated because the sensation of a things semi-perfect is pretty like a perfect one.
The explanation is because the more realistic and real-life like is your goal the more you need resources, not only CPU and GPU but cash too.
after this strange preamble I quote for the flag options, the method applicated is not much different than a normal Garbade Collector, you mark a no more usefull item and when the Garbage collector come he free the ram space used by this object, so this new space can be reused.
The same process is done by a lot of engine, and the destroy operation appens before the rendering calculations.
The final goal is always to reach a good in-between solution.
There is the possibility to force the instant destruction in every moment of the engine computation process, but this solution is always deprecated.
With the animation the way u typically use is to Destroy (setting flag to be destructed) at the end of the animation or in the last few frames.
At least you can use some tricks to make the fade more enjoyable (like particles).
The real problem is when you have to destroy object over the net (multiplayer games), in this case you have to establish what is the more attendible machine and pick that to calculate physics and interaction, this machine is always the server or the at least the host(depending on the game type).
I know that the question was marked as javascript question, but i couldn't resist to answer.
I enclose also a page from the unity documentation about the Destruct function were explain how they menage to remove item from a game enviroment:
https://docs.unity3d.com/ScriptReference/Object.Destroy.html
Have a nice day! and good coding.
In the Visual Event description, it says that it extracts "which elements have events attached to them". I can confirm this by running the bookmarklet and seeing all the colour highlights.
I would like to extract this information without the fancy presentation so that I can play around with it into a script (Ruby/Python/Perl). In other words, I would like to get a list of the divs (and their info ideally) from Visual Event.
Is there any way to do this without digging through the code on GitHub? Not to say that I'm not willing to do this, I was just wondering if there was an easier way.
There is no way to accomplish this very oddly specific task without digging through the code, although this isn't as hard as it seems considering it's quite legible and easy to build on your own system, even if you don't have any previous experience with JavaScript.
Having discovered requestAnimationFrame just a moment ago, I have dived into all the information I could find about it. To name just a few of the resources I came across in case there are others looking for more info about it:
http://creativejs.com/resources/requestanimationframe/ - explains the basics about it.
http://www.html5rocks.com/en/tutorials/speed/animations/ - explains how to use it.
Anyway, all of these resources tell me something about how requestAnimationFrame works or how it could/should be used, but none of them tell me when it is right to use it.
Should I use it for animations (repeated changes to the style of an element, much like CSS animations)?
Should I use it when an automated event wants to change the css/classes of one or multiple elements?
Should I use it when an automated event wants to change the text value of one or multiple elements? (e.g. updating the value of a clock once every second)
Should I use it when an automated event wants to modify the DOM?
Should I use it when an automated event needs values like .offsetTop, .offsetLeft and then wants to change styles such as top and left a few lines further?
Should I use it when a user generated event causes any of the above changes?
TL;DR: When is it right to use requestAnimationFrame?
You shouldn't yet. Not really, at least. This is still experimental and may or may not reach full recommendation (it is still a working draft at this point). That said, if you don't care about older browsers, or willing to work with the polyfill available the best time to use it is when you are looking to draw things to the screen that will require the browser to repaint (most animations).
For many simple modifications of the DOM, this method is overkill. This only becomes useful when you are doing animations when you will be drawing or moving items quickly and need to make sure that the browser repainting is keeping up enough to make it smooth. It will allow you to ensure that every frame you calculate will be drawn to the screen. It also provides a utility for more accurate time measurements to your animations. The first argument is the time at which the paint will occur, so you can ensure that you are where you should be at that moment.
You should not use it when you are doing many simple modifications to the DOM, or things that don't need to be smoothly transitioned. This will be more expensive on your users' computers so you want to limit this to making things smoother in transitions, movements and animations. Forcing a frame redraw is not needed every time you make a change on the page, since the response will be fast enough most of the time you don't need to worry about that extra couple milliseconds between draws.
As the previous answer says, you should not use it in the discontinuous animation because that don't need to be smoothly transitioned. In most cases, it's used for properties which vary continuously with time.
I am currently trying to code my own JS drag and drop script (out of sheer curiosity and boredom, I know it would be much easier with a framework). My aim is a fully working Firefox3 version , IE can wait for now.
I just got stuck on a weird bug. When I drag the div for the first time, it works ok. When I drag it for the second time, it does not stick after releasing the button and I have to click once more to get it down. Third and consequent drags work flawlessly again (!?!).
Please see [the original page][1] (as I said, FireFox only for now) for an idea of what happens. The whole thing is done as a div with two events (onmousedown and onmouseup) using document.captureEvents(Event.MOUSEMOVE) for the intermediate movement. The script can be found [here][2] (disregard the bottom ajax part, it is prepared for some additional tricks and the bug stays if I take it out).
Please let me know if you have encountered something similar in the past or if you see a mistake somewhere. I know there may be better ways to go around the whole thing but I am specifically looking for a way to make my approach work.
EDIT: Chrome and Safari work.
EDIT: Taking the links offline, working on new version.
Well first up this works for me in FF3 if that's what you're asking.
This isn't going to be what you want to hear, but I strongly recommend you pick up a DnD method from mootools or jquery or similar. Just from an efficiency standpoint, DnD is a horrible thing to code up (done it a few times myself) and if you're not capable (no offence meant here) of resolving the numerous bugs that come up it's just going to be a huge drain of your time compared to just going with a robust mature implementation off the shelf. It is a hard thing to do.
If you do what to continue with your own code (as an exercise or out of pride - I can appreciate that :) ) this kind of problem is typically the result of either an event not being captured where you think it is because some other event got in the way first, a flag not being set where you think it is, or (or because of) an error which breaks out of your code at an unexpected point. Try and trace logically what's happening by logging out the event triggers.
If you could define how it wasn't working in more detail I might be able to trace it further (since I seemingly can't replicate), but I do suggest you explore the benefits of a solid library.