Code Monkey home page Code Monkey logo

Comments (15)

jasondavies avatar jasondavies commented on March 29, 2024

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.

mbostock avatar mbostock commented on March 29, 2024

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"}});

from d3.

jasondavies avatar jasondavies commented on March 29, 2024

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]);
    }
  }
}

Assumes that {<function>: {<n>: <v>}} becomes <node>.<function>(<n>, <v>)

I'm not sure if it should be included in D3 because then it would affect parsimony (love that word!) as you say :)

from d3.

mbostock avatar mbostock commented on March 29, 2024

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.

jasondavies avatar jasondavies commented on March 29, 2024

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

from d3.

lashleigh avatar lashleigh commented on March 29, 2024

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.

NelsonMinar avatar NelsonMinar commented on March 29, 2024

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.

mbostock avatar mbostock commented on March 29, 2024

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.

mbostock avatar mbostock commented on March 29, 2024

See also discussion in #65.

from d3.

brettz9 avatar brettz9 commented on March 29, 2024

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.

mbostock avatar mbostock commented on March 29, 2024

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.

brettz9 avatar brettz9 commented on March 29, 2024

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.

brettz9 avatar brettz9 commented on March 29, 2024

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.

mbostock avatar mbostock commented on March 29, 2024

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

from d3.

mbostock avatar mbostock commented on March 29, 2024

Folding this discussion into #277.

from d3.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.