What should I use to write standard views for my packages?


#1

I’ve been researching a bit about different approaches for this. But I didn’t get anything but more confusion.

Should I go with space-pen, any other framework or just plain HTML & CS? I don’t need any of those fancy things for the views I have in mind ATM. So it’s just a mater of stay in the ecosystem with minimal effort after future changes in the core.

The most relevant info and what’s making me doubt is the following issue in github:


Trouble with creating popup list in current editor
#2

I would probably recommend just using HTML custom elements as the core packages are. Space Pen is definitely an easier ramp up though I feel like it is going to entrap you on the other side of a wall that’s just going to get higher over time.


#3

HTML custom elements? Similar to Polymer?


#4

I don’t know, I haven’t used Polymer or even looked at it yet :grinning:


#5

Polymer is an ‘framework’ (I’m not sure if It should be denominated this way) on top of web components. Making it easier to create self contained components.

Actually it makes easier to create elements in a more declarative way, and adding features like double data binding.
The discussion with polymer is that it pollutes the global scope. In my experience this is not true, but I’ve never been looking into polymer deeply enough and I might be missing some important concept. Another point is that I don’t know how it may affect the loading time, Shouldn’t be too much.

Probably the way to go here is try it and choose by proof. I’ll do some experiments this weekend both, with standard components and with Polymer.

@benogle was trying it but finally refuses to use it arguing the global pollution.


#6

We really do need a standard view framework.

That said, I wouldnt use polymer, or elmer (the thing powering template-explore).

I would use HTML templates. No data binding, but much better than manually creating nodes. Notifications uses it: https://github.com/atom/notifications/blob/master/lib/notification-element.coffee

Though it isnt a very pretty example. Obviously data binding would make that example much nicer.

I made a template helper to make stamping them out easier: https://github.com/atom/notifications/blob/master/lib/template-helper.coffee

The basic pattern is this:

TemplateString = """
<div class="a-div">wowza</div>
"""
template = TemplateHelper.create(TemplateString)
aParentNode.appendChild(TemplateHelper.render(template))

#7

Programmatically adding elements is a non-starter. Adding views should be as easy as the old space-pen. It doesn’t have to use query.

Edit: I just realized you meant for the whole view to be inside the template, not use appendChild to build up everything. However, writing out HTML is also a lot harder than space-pen.

I wrote a spec for a “space-pen-2” and announced it on atom/atom after I received some encouragement. It didn’t use jQuery and supported the DOM style that core is using now. It also had all the advantages of the old space-pen. The best of both worlds.

I got no feedback and I’m not going to put in the large amount of work on it and have it ignored.


#8

At some point we’ll have something nicer, but for now, that is my recommendation.


#9

See my edit above.

texttomakestupiddiscoursehappy.


#10

@mark_hahn can you share the link for the specification sheet for your ‘space-pen-2’ spec? I’ve seen it before but I didn’t bookmarked it and I can’t find it now. I would like to take a look on it, just for the sake of curiosity.


#11

I think @mark_hahn will agree that the starting discussion was this one:

BTW @mark_hahn, have you looked at my SpacePenDSL mixin? As its name says, it provides the space-pen DSL for custom element:

Maybe it could be a starting point for the features you envision for space-pencil?


#12

That looks good. It might be all I need. I wish it were as easy to find npm modules like this as it is to find Atom packages.


#13

https://gist.github.com/mark-hahn/3f9ee0ba4945a285fb38

I really really like this spec. It is clean, easy to use, and meets the requirements of providing space-pen DSL, supporting web elements, and modern binding.

I was going to write this, then when I got zero interest I reluctantly decided to kill it because it would be a lot of work for just my usage.

Does anyone think they might possibly use it?


#14

It is possible I might be able to fork this as a start for implementing space-pen-2. Would you have any interest in the new space-pen? It appears you like the old DSL also.

Edit: Duh, I see you already suggested this.


#15

Everyone interested in this topic should check out https://github.com/atom/atom/issues/5756


#16

I’ve been watching the GitHub issue for a number of months. Given a decision doesn’t appear to have been reached, what’s the best way to write my views for my new package? I’ve been using the bug-report package as my starting point; I tip my hat to @leedohm for a readable package. However it uses Space Pen, and I’m trying to understand the consequences to my package’s maintainability if I follow suit.


#17

Thanks for the compliment. I’m glad it is helpful :grinning:

Space Pen works fine for now. There are no plans to extend it in the future, though. So depending on how things change, it may not be able to keep up. On the other hand, given how generically it is implemented, I have a hard time seeing it unable to be used.