Skip to content
This repository has been archived by the owner on Jul 30, 2018. It is now read-only.

AMD Plugin Interface #59

Closed
kitsonk opened this issue Jul 27, 2015 · 9 comments
Closed

AMD Plugin Interface #59

kitsonk opened this issue Jul 27, 2015 · 9 comments
Assignees
Milestone

Comments

@kitsonk
Copy link
Member

kitsonk commented Jul 27, 2015

Shouldn't we put the AMD plugin interface as a specified interface either in core, or dojo/loader?

I noticed that in the core/has implementation, it isn't relying upon an interface, therefore potentially exposing an API that isn't consistent. One of the strengths of TypeScript is being able to collate these interfaces and expose them to others.

@kfranqueiro
Copy link
Member

I would think definitions for this would belong in dojo/loader, except if we still have any thought of being able to interoperate with other loaders, in which case adding an unconditional dependency on a loader you might not use would seem undesirable, and core would be the next best place since most other packages are likely to depend on that.

@edhager, @bryanforbes, thoughts?

@kfranqueiro
Copy link
Member

Also, would this idea actually work for modules, especially in cases where we're exporting individual functions? (i.e. is it even feasible to say that a module's exports collectively implement an interface?)

@kitsonk
Copy link
Member Author

kitsonk commented Jul 27, 2015

Well it appears it exists partially in core/load. I suspect we just need to move some/all of these interfaces somewhere else and dojo/has should implement them.

@kitsonk
Copy link
Member Author

kitsonk commented Jul 27, 2015

load is missing a Normalize interface though.

@kfranqueiro
Copy link
Member

Isn't that just an interface for AMD's require as called by consumers, and not specifically for plugins?

@kitsonk
Copy link
Member Author

kitsonk commented Jul 27, 2015

DOH! You are correct, though I did find it in dojo/loader though. It seems the whole thing is already there, but I know we were trying to avoid a hard dependency on the loader. Is it better located somewhere else?

@bryanforbes
Copy link
Member

I wonder if, like lib.d.ts or node.d.ts, there needs to be an amd.d.ts that can be shared by projects that will work with any AMD loader.

@msssk
Copy link
Contributor

msssk commented Aug 7, 2015

Currently, dojo-core has an incomplete AMDRequire interface defined in load.ts. There is a more complete interface defined in dojo/loader, so should we use that (PR)? Or should we extricate AMD definitions into amd.d.ts? Where would amd.d.t.s live (what project)?

@morrinene morrinene assigned bitpshr and unassigned morrinene Dec 21, 2015
kitsonk pushed a commit to kitsonk/core that referenced this issue Dec 30, 2015
@kitsonk kitsonk assigned tomdye and unassigned bitpshr Feb 11, 2016
@kitsonk kitsonk added this to the beta.1 milestone Feb 29, 2016
@kitsonk kitsonk modified the milestones: 2016.04, beta.1 Apr 8, 2016
@kitsonk kitsonk modified the milestones: 2016.05, 2016.04 May 3, 2016
@kitsonk kitsonk modified the milestones: 2016.06, 2016.05 Jun 7, 2016
@kitsonk kitsonk modified the milestones: 2016.06, 2016.07 Jul 4, 2016
@kitsonk kitsonk modified the milestones: 2016.07, 2016.08 Aug 1, 2016
@kitsonk kitsonk removed this from the 2016.07 milestone Aug 1, 2016
@kitsonk
Copy link
Member Author

kitsonk commented Oct 4, 2016

We can close this issue for now and revisit if needed.

@kitsonk kitsonk closed this as completed Oct 4, 2016
rorticus added a commit to rorticus/core that referenced this issue Dec 9, 2016
rorticus added a commit that referenced this issue Dec 13, 2016
…250)

* Adding extended observable to implement some RxJs methods, shim #59
* Review feedback, shim #59
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants