Showing posts with label javascript. Show all posts
Showing posts with label javascript. Show all posts

Tuesday, April 25, 2017

mobile touch gotcha

I once made an angular firebase demo site called Fridge Magnets With Friends.
You can move magnets around on a virtual fridge. This involves a lot of dragging elements.
One day mobile drag stopped working, even tho I employed the clever jquery ui touch punch.

I spent hours switching the whole thing to use ngDraggable, because their mobile demo did work in mobile. Altho using ngDraggable required me to take out jquery (actually it didn't, but some forums said that would help make it work in mobile) - so I spent a while redoing the angular app without jquery.
Moment of truth: no luck.

Finally I hijacked the browser with a little shim code:
        $document.on('touchstart', function(e){
            console.log(e)
                            });

Because for the life of me I couldn't figure out why my elements weren't receiving the touchstart event in mobile.
This way I could see what element the e event was pointing to.
Turns out my footer CSS was very improperly done and covering the entire screen, so the event for touchstart, which has to have a stoppropogate() for other reasons in mobile only, never made it to the dragable elements.
Took out the footer and both solutions started working; however, jquery-ui + touch-punch still worked better than ngDraggable, so in the end, 4 hours of work (work that was, admittedly, kind of fun) got reduced to commenting out a couple lines of html. At least I understand mobile touch events now.

facepalms: 9.5

Saturday, March 11, 2017

quick note on webpack imports and es6 class inheritance

I know it's crazy that I'm only now using modern javascript class inheritance for the first time, but I've been more of a backend programmer most of my career.

I've got a new hobby project that I'm doing with modern webpack / es6 / vue.js, and I just learned something that I didn't find an obvious answer to in the googs.

Basically, I'd been creating utility files with instantiated objects saved as var whatever or let whatever and then exported at the bottom:

export default {
  obj: obj
}

And this was all well and good. But then when I wanted to define a class in the same file, the export default was overriding keyword "this". So the functions defined on the class referencing this were actually referencing my export default. I could use a fairly circular reference to get back to the instantiated class object, but really that whole route is silly.

The way to make this work is to define (but not instantiate) each class in its own file. The class itself is your export default in that file:

export default YourClass extends Whatever {
  constructor () {
    this.stuff
  }
  yourFunction () {
    this.stuff + 1
  }
}

Then instantiate the class and use it in another file. Should have been obvious but well es6 takes some getting used to.

Monday, February 23, 2015

talk about facepalms

learning javascript: valuable
relearning trigonometry: way valuable
spending 2 hours trying to code Math.atan2 in plain javascript because you were too stubborn to spend 6 seconds searching for how to get that stupid angle at any quadrant of the unit circle: priceless!

in related news, Math.atan2 is very useful (altho why its arguments are (deltaY, deltaX) and not vice versa eludes me), and pixi.js is very fun.

Tuesday, July 12, 2011

holy sweet victory

Just figured out something that's been bugging me nonstop for weeks, which has no documentation online: the jquery plugin fancybox doesn't like to have its stuff overwritten, which is to say, you shouldn't define something like this:
var fancy_box_options = fancy_box_defaults;
fancy_box_options.type = 'iframe';
fancy_box_options.width = 696;
fancy_box_options.height = 499;
fancy_box_options.scrolling = 'no';
fancy_box_options["onStart"] = function(link){
var new_link = $.param.querystring($(link).attr("href"), "gmail=" + $("#gmail").val());
$(link).attr("href", new_link);
};

$("a.iframe").fancybox(fancy_box_options);
$("a.iframe_defaults").fancybox();


In one function, and then soon after define:
<% if current_user && @popup_help %>
var fancy_box_options = fancy_box_defaults;
fancy_box_options.type = 'iframe';
fancy_box_options.width = 696;
fancy_box_options.height = 499;
fancy_box_options.scrolling = 'no';

fancy_box_options.href = '<%= popup_help_path(:gmail => current_user.email) %>';
$.fancybox(fancy_box_options);


in another. You'll get a wholly unhelpful error about href being undefined.

All better now -
#facepalms only 4, because I already had a lot of trouble with this previously, I'm over it now, and the sweet release of figuring it out is worth so, so much.

Sunday, May 1, 2011

Rails 3 Unobtrusive Javascript is Unintuitve

So what I wanted to do was link from a partial view to a controller method through a route which took a title parameter and from the controller method run a javascript file in order to append content to a div with a unique name defined by the title param.
In django it's pretty straightforward, but ruby on rails 3 had me scratching my head for a good long while.
Here's the solution, or at least the parts that were difficult:
the link:


<%= link_to "Comments", show_comments_path( :format => 'js', :comment_id=> session[:id] ), :remote => true %>
This whole :remote => true business tells rails 3 that this is an ajax call. The :format param does NOT get passed into the url, but DOES render the response as html, most of the time. Which is to say, rails will run the .js.erb file with the name matching your route.
Here's the route:
match 'show_comments/:comment_id', :to => 'deals#show_comments', :as => :show_comments
So first rails runs the show_comments method from the appropriate controller, which you can use to set state variables for the javascript. Then, whatever is in show_comments.js.erb will be run, and the current page will NOT be reloaded or redirected. No partial needed. No view needed. The controlling method will do all of this as the default return, so no return or render needed either, only the .js.erb file which has your prototype or jquery calls, or whathaveyou.
facepalms: 4 (steady, slow, only slightly infuriating progress)

Thursday, April 28, 2011

event data in jquery

this one stumped me for quite a bit. If you want to bind a click event to a div id in jquery to a preexisting function which takes arguments, you need:
$('#id').click({param: param}, function_to_run );

to bind it. Here, id is the id of the div or whatnot, param (the second one, the first one could be anything) is the variable you want to send, and the function_to_run is already written. No parens after the name, you're sending it as an object.

The tricky part is in the function itself:
function function_to_run(event) {
param = event.data.param;


get it? The click event sends the event itself as the one argument to function_to_run, and the parameters you give it are stored in data. just so you know.

around a 6 on the facepalm scale.