JS function that returns a function in order to bind an attribute.

example.js

function markRowHidden(dataAttribute) {
  return function() {
    var tr = $(this).closest('tr');
    tr.data(dataAttribute, true);
    tr.hide();
  }
}

$("tr form.type1").on("submit", markRowHidden("attribute1"));
$("tr form.type2").on("submit", markRowHidden("attribute2"));

function markRowHidden ($el, attribute) {
    var tr = $el.closest('tr');
    tr.data(attribute, true); //consider moving this to a JS object if possible
    tr.hide();
 }
$("tr form").on("submit", function (e){
   console.log(arguments, this) // my favorite exploratory expression
  markRowHidden($(this), "attribute1"):  //pre-wrapping the element in jquery here prevents a hard dep in the function body
  markRowHidden($(e.target), "attribute2"); // I prefer using the event parameter over this. Equivalent to the line above
})

Blah, plenty of iPad related typos in there but you get the gist.

If you're keeping track of the hidden nodes then an array might be more straightforward.

hiddenElements.push($el)

The real question is what are you trying to accomplish. It's not that returning dynamic functions is uncommon, it's just confusing. There has to be a way to do what you mean to accomplish without dynamically assigning an anonymous function. I avoid anonymous functions as much as possible. Without the context of the requirements, I would want something like this:

$("tr form").on("submit", obviousFunction);

P.S. I also try to avoid putting data in my markup. Sometimes it's necessary but most times it's not. It's a slippery slope when you start maintaining state in HTML.

NOTE: One change, I made the selectors different, so that you couldn't combine them like @theotherzach did (the two change events now target different form elements).

@theotherzach Thanks. I like how you moved the jquery wrapper up top. I was already annoyed by how each function was having to do that. Also like the array idea, I had a similar but shittier idea in mind. Regarding "consider moving this to a JS object if possible", what's the advantage of that over leaving it on the DOM element, essentially treating that element as a data structure?

@daytonn I translated my problem a bit wrong, the selector for the two is actually different. There are rows in a table, each row can be hidden for as many as two reasons (it has been marked inactive, or it has been permanently hidden). For each of the two reasons, there is a form in the row that will send a PATCH request to the server to hide that row. Now I need to remove it from the form. But there is also a button to show inactive rows, and another button to show permanently hidden rows, so I need to keep track of why that row is hidden. Thus the same javascript code (hide the element, set its class or data attribute so we can remember why), but with different values.

Re: Dom data vs js state:

If you're mutating, it's state. I like to isolate my application state in tiny js data structures The rest of the app runs as a function of those microscopic objects and the collections fetched from the server.

This article is about react, but doesn't require the use of react: http://facebook.github.io/react/blog/2013/11/05/thinking-in-react.html