API for creating views in packages #3752
Comments
|
Is that really required? What if the packages also would just extend HTMLElements as views? I recently rewrote my package witch HTMLElements instead of using SpacePen and it worked great. |
|
After discussion and tinkering, we have a direction. The goal is a view system that uses the browser's built in mechanisms as much as possible, embracing new tech like custom elements and We're encouraging a Model/View approach. Models are just plain objects. e.g. This is a fine model: Model = {
message: 'Find in Buffer'
}A model class: class FindModel
message: 'Find in Buffer'
constructor: ->Views are custom elements with an HTML template. Templates support Polymer's template data-binding. We'll provide a Example: Find panelModel class FindModel
message: 'Find in Buffer'
constructor: ->
search: (text) ->
# do search on current editorA custom element view: {registerElement} = require 'element-kit'
Template = require('../templates/find.html')
FindElement = registerElement 'my-find',
createdCallback: ->
@appendChild(Template.clone())
@rootTemplate = @querySelector('template')
@input = @querySelector('atom-text-editor')
@classList.add 'tool-panel', 'panel-bottom', 'padded'
atom.events.add this, 'button', 'click', -> @confirm()
atom.events.add this, 'core:confirm', -> @confirm()
confirm: ->
@model.search(@input.value)
getModel: -> @model
setModel: (@model) ->
# setup the data binding
@rootTemplate?.model = @modelAnd the template in <template bind="{{}}">
<div>{{message}}</div>
<div>
<atom-text-editor mini></atom-text-editor>
<button class="btn">Search</button>
</div>
</template>Registration. We need to tie the View to the Model with the view provider system: atom.workspace.addViewProvider
modelConstructor: FindModel
viewConstructor: FindElementInvocation. Create the model, then attach a panel: @model = new FindModel
@panel = atom.workspace.addBottomPanel item: @model |
|
Very powerful. It is a shame it is so much more complex. On Mon, Oct 27, 2014 at 11:31 AM, Ben Ogle notifications@github.com wrote:
|
|
I like the resemblance of Polymer in this. Google are pushing that thing pretty badly and it's well thought out to really become big. Also, everything that uses a web components approach is probably the right way forward. |
@mark-hahn can you elaborate? There are definitely more distinct entities: a model, a view, a template, and registration. But overall, UIs built with this should be simpler. Data binding will remove a bunch of logic, and the view should have very little logic, just calling things on the model. |
|
I was just comparing it my usual spacepen view, object model, and jquery On Mon, Oct 27, 2014 at 12:33 PM, Ben Ogle notifications@github.com wrote:
|
|
Space pen is going away, so something like this will be the only way. 2 ways to simplify:
view = document.createElement('my-find')
@panel = atom.workspace.addBottomPanel item: view |
That would be nice. I noticed in the docs that the state serializer used
That's a shame. The barrier to entry for new package developers will So that means I will have to rewrite the views on my 12 packages. I guess I have but one request. Please think through carefully what benefits On Mon, Oct 27, 2014 at 1:55 PM, Ben Ogle notifications@github.com wrote:
|
I suppose I should clarify. You can still use
I took this as an opportunity to collect my thoughts over the last few weeks into a bit of text. This new system will be a net positive for everyone. Even in small packages, the resulting code should be simpler. Data binding is a huuuge dev speedupIf you've ever used data-binding in a webapp but it is amazing in its ability to speed up the dev process and reduce logic. No longer will we need to write logic to update the view like this or like this. Just set a property on an object and watch it from the template. An interesting example is making a view toggle when clicking a checkbox. All that's necessary is this: model = { showIt: false }<label>Show it? <input type="checkbox" checked="{{ showIt }}"></label>
<template if="{{ showIt }}">Shown via `if`</template>Another example: Note how this space-pen view has more cruft than an element using template bindings. The The learning curve should not be any steeper than Performance
I've run some benchmarks. Creating and appending 1000 elements with template bindings shows a ~35% gain over space-pen. Creating and appending 1000 elements with a template and no bindings shows a 95% gain over The bindings are run async, so the impact to startup time should be that of the NO bindings case. Less CruftWe rely on jQuery which does a bunch of things we dont need because we know the platfom. jQuery's big win is a consistent API across all browsers, with some sugar here and there. The browser APIs are getting good ( We made up The FutureOverall, we're preparing for the future. We're betting that the API's eventually baked into chrome will be The Best Way to write views. We're betting that, eventually, libraries like jQuery and backbone and angular and This is just the foundation. We've written it in a minimal way initially on purpose — we're only providing the html require and |
|
I'm still concerned about coding effort for small packages. The problem is overhead. You cheated on the first Having two files instead of one is a PITA. I've never had to deal with an html file so far in Atom package development. This is a big step backwards. Even if I have to deal with crufty old html I can still put it in the same single view file, right? The coffeescript html representation in space-pen is awesome, much like coffeescript itself, and I hate to lose that. The Performance of markup has been a zero issue in my packages so far. They usually have no more than a dozen elements. The 35% gain you quote is not impressive especially since the space-pen rendering is a whopping 357 microseconds. And this usually only happens once when the package is activated.
Not in my lifetime, if ever, although I'm quite old. Remember I am only considering package developers like me. I have no doubt these changes are awesome for the core rendering. Also note that I realize this has to be done. But keeping an easy route for package developers is paramount in my mind. Maybe I'll take a stab at making some tool to create everything easily for dummies. |
First of all there is a massive difference between 357 microseconds and 357 milliseconds (ms), three orders of magnitude to be exact 😜 Joking aside, while you might think this win is small, consider the total number of views that might be in play with a fully configured Atom environment with dozens of third-party packages on top of the core ones. Also the views in packages should (ideally) be created and destroyed whenever necessary/possible to reduce memory footprint etc, so a speedup here is a huge win in the overall perceived performance of Atom. Also separating things into multiple files should make everything more manageable in the long run — separation of concerns. This also leads to small wins such as being able to more easily reuse views, and compose views from smaller partial views. I for one, love these changes, and I guess there's a reason why the concept of model binding etc. keeps getting reinvented about every 10 years (fourth time now?) in one form or another. It's generally a nice concept once things reach a certain level of complexity within a system, but it does demand a bit more of the developer though, that part I do agree with. |
I assumed the print-out shown was the total of the 1000 runs. Which is it? I'm pretty sure it is microseconds since there is no way that amount of code could take 1/3 of a second. @benogle, I realize I have been representing the opposition of change here. I hope I'm not just knee-jerking a reaction to change as I suggested one might knee-jerk an acceptance of cool new features. How big is the |
|
I have thinking a lot about this (way too much) and I think my problem isn't the semantics as much as the syntax. I see this native html as noisy, hard to read, too much typing, and too many files. jQuery and space-pen had some useful features to hide that kind of cruft. Is it possible there could be a space-pen sequel that does for the new html/bindings what the original space-pen did for the old html? This would be of general interest to all web developers, not just Atom, so there must be something happening in this direction somewhere. If not I'll have to put my coding where my mouth is and try to come up with some ideas. BTW, I'm having a problem understanding this ... Since when can you |
Since 82267c0 😃 |
|
I have been on a rant and I apologize. I said that this was right for Atom core and now I realize packages have to exactly match core. P.S. Separation of concerns has nothing to do with files. Separating html by putting it at the top of the view file is a great separation. To me keeping the view in one file is a great feature. A view is really a kind of single concern when compared to a model. |
Agreed, but encouraging separate files also encourages the separation of concerns (at least more so than now). That being said, I do still believe you can inline your views if you prefer that approach. Although it will likely not be as "pretty". |
|
We won't be using SpacePen in core, but I see no problem with people continuing to use it if it's a good fit for their packages. We'll need to make a couple slight breaking changes to enable it to keep working in packages without support from core, but the library should continue to work indefinitely. |
|
We've all talked about this and decided 2 things: the injection of globals via polymer isnt something we want to support long term, and it doesnt exactly fit in with the API freeze (it's additive). We plan to revisit this when we're into 1.0 initiative and can spend more time on it. For now, @nathansobo is updating space-pen to be forward compatible and used outside of core. We will have a period of time between the freeze and 1.0 where our a recommendation for view code will range from vanilla custom elements to space-pen. The stuff I outlined here is at https://github.com/atom/elmer and https://github.com/benogle/template-explore for future reference. |
Awesome. Thanks. On Thu, Oct 30, 2014 at 2:29 PM, Ben Ogle notifications@github.com wrote:
|
|
I opened #5756 with a high-level overview of where we're at today and started a list of options. I'm closing this issue in favor of that one, in the interest of starting fresh with the current thinking & requirements. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks! |
If we plan to deprecate the space pen
Viewclass, we need a story for what folks can move to. Some kind of system that interoperates with custom elements. Something that UI heavy packages like settings view and fnr can use.We need to do more thinking.
The text was updated successfully, but these errors were encountered: