Public Interface for GUID creation within Ember

Proposals
1

Would it be possible to add a public interface to the Ember GUID process.

Ember.createGuid();

no input required just returns an guid that persists for the lifespan of the ember application

Ember.createGuidFor(obj);

You provide the object and it would return a guid that persists so long as that object exists.

These could alias or piggy back off of the private method

Ember.guidFor();

Use case: There are occasionally specific cases where it would be useful to have a built in function that can just return a guid. Especially in creating complex D3 charts where you want to easily reference objects and create arbitrary (but unique) ids.

I realize I can just use Ember.guidFor() but because it is a private method, feels a bit wrong.

Welcome hearing any pros and cons. I think I have a general idea of how guidFor works but there may be other framework implications to consider.

Note: moving discussion from Github to Discourse.

3 Likes
2

I’m all for Ember offering a public interface to creating or fetching guids. Makes sense to me.

3

I don’t know that this discussion is generating much interest, but I am also a proponent.

My use case has an incredibly easy workaround (creating my own counter), but being able to access Ember’s GUIDs would be far more elegant. I don’t even care about GUID creation just retrieval. But I can see where somebody might want that as well.

I’d also be interested in hearing if anyone can see any downsides to this.

I know that keeping things Semver compliant in future releases is an issue…

4

FYI: Here is what I am doing.

App.RadioGroupComponent = Ember.Component.extend({
  willInsertElement: function(){
    this.set('name', 'radio-' + Em.guidFor(this));
  },
  ...
}

Like I said, I think it is more elegant than doing something like App.myCounter or whatever.

1 Like
5

Is it still a bad idea to use guidFor? Even though it’s a private method?

I’m using it specifically for instances where I am creating jQuery Events which set properties on a view. I have my own guid utility which creates a guid on init of the view, but it’d be nicer to use something baked into Ember itself.

code example:

// Currently doing this
this.guid = this._newGuid();
this.get('scrollableContainer').on('scroll.' + this.guid + '', function (evt) {
  this.set('scrollY', Em.$(evt.target).scrollTop())
}.bind(this);

// This feels so much more Ember
this.get('scrollableContainer').on('scroll.' + Em.guidFor(this) + '', function (evt) {
  this.set('scrollY', Em.$(evt.target).scrollTop())
}.bind(this);

Would love feedback on what the best way to do this would be. Thanks!

7

YES ! This feature is a must have !

8

So as it turns out. It’s actually not a terrible idea to use Ember.guidFor().

After learning more about how Ember.guidFor() can fetch a GUID for DOM elements, I feel it’s safe to use in production code. While it is a private method, I’ve used it to assign events or check event.targets while matching the GUID for the target element and the original element. It’s just always important to insure you’re passing a DOM element and not a jQuery element.

var element = Ember.$(element)[0];
var elementGuid = Ember.guidFor(element);
9

I’d like to add my two-cents to this very old thread. I’ve been trying to solve a problem that seems, on the surface, very simple. I want to have a reusable Ember component with a <label> element that references an <input> element. The problem is that id values will conflict between different instances of my component.

With Ember.guidFor, fixing this becomes pretty simple:

test-component.hbs:

<div>
    <label for={{text1Id}}>Huh:</label>
    {{input value=text1 id=text1Id}}
</div>

test-component.js:

import Ember from 'ember';

export default Ember.Component.extend({
    text1Id: function() {
        return Ember.guidFor(this) + "_text1";
    }.property(),

    text1: null
});

There’s an underlying problem that “id” values aren’t isolated inside an Ember component, which, I hope someday would be fixed by the use of Web Components and Shadow DOM. But until that is a reality, using Ember.guidFor is a straight-forward method to manually isolate my ids by component.

Is there some other solution that has escaped my notice?

1 Like
10

What is the difference between Ember.guidFor and this.get('elementId') in components? For example I’ve been doing this which is basically the same as yours:

export default Ember.Component.extend({
  text1Id: Ember.computed('elementId', function() {
    return `${this.get('elementId')}_text1`;
  })
});

However, after writing this post I realized a better option is to create a HTMLBars helper:

import Ember from 'ember';

export default Ember.Helper.extend({
  compute([obj, suffix='']) {
    Ember.assert('Must provide an object to guid-for', Ember.isPresent(obj));
    return `${Ember.guidFor(obj)}${suffix}`;
  }
});

<fieldset>
  <label for={{guid-for myValue}}>Label:</label>
  {{input value=myValue id=(guid-for myValue)}}
</fieldset>

An example: JS Bin - Collaborative JavaScript Debugging

11

Is there any reason why we are not supposed to access Ember.generateGuid() at all?

Why is Ember.uuid() public then?

Can someone please explain the rationale behind this?

12

FWIW from what I can see, Ember.guidFor() is now public.