A more compact attribute syntax? about d3 HOT 15 CLOSED

I like this idea, I thought about suggesting it too! It does take a bit longer to type .attr(...) all the time so a more compact syntax could be good. Are there any downsides?

from d3.

That sounds reasonable to me, although I'd prefer to use a separate method (say, attrs plural) rather than attempting method overloading through argument type inspection. The only downside I see is object literal creation cost, but that's minimal.

There's also the API parsimony downside, which I think is more significant. Presumably we want to extend this to style as well. So should there be a styles method, too?

Or… not that this is a good idea, an apply method that takes an object with both style, attr, and whatever else we want to apply to the selection?

p.append("svg:circle")
    .apply({attr: {cx: 250, cy: 240, r: 40, fill: "#F00", stroke:"black"}});

I think .apply({attr: {...}, style: {...}}) starts to look a bit less readable, but maybe it would be useful in specific cases. I guess something like this is super-simple to write anyway e.g.

function apply(node, nodeFunctions) {
  for (var name in nodeFunctions) {
    var f = node[name], args = nodeFunctions[name];
    for (var argName in args) {
      f.call(node, argName, args[argName]);
    }
  }
}

That's pretty clever. We could add that as d3_selection.apply(nodeFunctions). Although it wouldn't work for the single-argument methods such as html and text.

from d3.

I guess we could add some typeof testing in there so that {html: "", text: ""} works as expected (and numbers too).

from d3.

Thanks for considering this, I really appreciate it. Let me know if you need anybody to test out a new format, I'd be happy to help.

from d3.

An alternate syntax I used initially by accident:
.attr("cx", 150, "cy", 140, "r", 40, "fill", "#F00", "stroke", "black");
It's a bit magic in positions, but seemed natural enough when I typed it.

from d3.

I'm learning towards the initial recommendation of a map for attr and style, so that we don't have to deal with type-inference for html and text. If we use a separate name for attrs and styles, then we can avoid the method overloading confusion, potentially (although the names look similar).

Although, there's another question here, should you be able to pass a function to attrs that creates a new object for each element? For example:

.attrs(function() { return {"cx": 150}; })

Or can you assign a function to an attribute of the map?

.attrs({"cx": function() { return 150; }})

Supporting both seems like a pain, but I kind of like the idea of allowing a function that generates a map—that way you can actually set different attributes on different elements in the same selection, which might be useful. It also would allow us to build helper classes that set multiple attributes (although we can do that already using call).

from d3.

See also discussion in #65.

from d3.

I think this compact approach would make sense for "style" and "on" as well, and the second argument to append (to eliminate need for attr/s in many cases).

from d3.

So, having a single argument version of attr, style and on sounds reasonable, rather than creating plural-named versions of these methods that look almost identical.

Supporting a single-argument function that generates a map sounds less desirable than a single-argument map; and if we take a single-argument map, then we should allow the values to be functions for consistency with the existing interface. That suggests we could support taking a map for attr, style and on—and defer supporting a function that returns a map until a future release (if at all).

Lastly, I'm against append taking an additional argument. Then we'd need a third argument to insert, too, and it makes attributes better supported than styles. I'd like them to be equivalent, and I think it's reasonable to require one attr to set attributes. :)

from d3.

Great, that sounds cool to me, thanks!

Brett

On 3/23/2011 12:53 PM, mbostock wrote:

So, having a single argument version of attr, style and on sounds reasonable, rather than creating plural-named versions of these methods that look almost identical.

Supporting a single-argument function that generates a map sounds less desirable than a single-argument map; and if we take a single-argument map, then we should allow the values to be functions for consistency with the existing interface. That suggests we could support taking a map for attr, style and on—and defer supporting a function that returns a map until a future release (if at all).

Lastly, I'm against append taking an additional argument. Then we'd need a third argument to insert, too, and it makes attributes better supported than styles. I'd like them to be equivalent, and I think it's reasonable to require one attr to set attributes. :)

from d3.

On 3/23/2011 12:53 PM, mbostock wrote:

Lastly, I'm against append taking an additional argument. Then we'd need a third argument to insert, too, and it makes attributes better supported than styles. I'd like them to be equivalent, and I think it's reasonable to require one attr to set attributes. :)

Sure, it's reasonable, but it's used a lot, and I think attributes tend
to be associated pretty readily with the element named before them (as
in HTML/SVG).

I'd think that styles could also be treated as an attribute if "style"
were specified as a key in the map. Yes, it would mean styles wouldn't
get first class treatment, but it seems to me it should be easy for
people to accept that styles inherently require more complexity (and
thus deeper nesting) compared to other attributes (which "style"
essentially is) since they have their own properties--unless you were to
risk name conflicts by checking for style properties on the map. But, in
any case, styles would still be possible in this scenario, perhaps
meeting your concern?

But whatever you like is ok with me.

Thanks,
Brett

from d3.

See pull request #179. Should be able to incorporate this into the next release!

from d3.

Folding this discussion into #277.

from d3.