Skip to content
This repository

Add Derby.js #141

Closed
addyosmani opened this Issue · 24 comments

5 participants

Addy Osmani Sindre Sorhus Nate Smith László Bácsi Michael Nelson
Addy Osmani
Owner

Was just speaking to a developer using this today. May be worth reviewing further for inclusion.

http://todos.derbyjs.com/derby

http://derbyjs.com

Nate Smith

One of the Derby authors here. If someone would be willing to start porting the standard TodoMVC app to Derby, we'd be very appreciative and happy to help out.

Sindre Sorhus
Owner

Looks very interesting! Reminds me of Meteor.

Addy Osmani
Owner

@nateps I havent been able to get this demo running on the official derby site, but would there be enough here to refactor into an implementation we/someone else could take further? https://github.com/codeparty/derby-examples/tree/master/todos

@sindresorhus just for context, you might find this a useful read as I did: http://blog.derbyjs.com/2012/04/14/our-take-on-derby-vs-meteor/. At some point we'll want to break out the real-time/real-time like frameworks into their own category probably.

Sindre Sorhus
Owner

@addyosmani Very interesting post. I know it's biased, but I love their thinking. I like Meteor, but this one sounds even more awesome: Reuse NPM, two way binding, modular, being explicit, STM and OT, datastore portability, and more. Can't wait to find some time to try this one out!

Addy Osmani
Owner

@nateps if you or a member of your team would be able to update the app to (at minimum) use our V1 template, I'd be happy to pull this into our labs site. You guys could then work on updating some of the other minor details to match the app specs when you have time. We'd then review and merge into master when ready.

As we're lining up for a big release near the end of the month it might be a good opportunity to get a few more people looking at Derby :)

László Bácsi
lackac commented

I've talked with @nateps about this and I'm going to take a crack at it.

Sindre Sorhus
Owner

@lackac Awesome! Let me know if you have any questions, and make sure to read the App Spec.

Sindre Sorhus
Owner

@lackac We're closing in on the release, which is next week. What's the status of this?

Addy Osmani
Owner

If we can get enough of this together that its mostly functional we could at least get it into labs with a view to a stable one making it into stable apps for 1.1. Just a thought.

László Bácsi
lackac commented

I've started to work on this in my fork, but unfortunately I haven't had much time for it.

After I had taken on this assignment I was told that we need to find a new apartment and I had to devote most of my time to finding a new apartment and other preparations. We're going to move next Monday so I don't think I'll have more time until next week.

Maybe @nateps could help out.

Sindre Sorhus
Owner

Moving this to 1.1

Sindre Sorhus
Owner

@lackac @nateps Would any of you get the chance to work on this for 1.1? We would really like to have Derby.js included, especially since we already have Meteor and would like something to compare it to.

László Bácsi

I hope I'll have some time on the weekend. @absoludity has offered to help as well on the Derby.js google group. By when should it be ready?

Sindre Sorhus
Owner

Awesome!
No deadline, but sooner the better ;)

Michael Nelson

Hi! I've had some time during the evenings this week, and have implemented all the main functionality. I've done a 2 minute demo which you can check if you like.

I've just been through the spec again and noted the things that I still need to do before I'll submit the pull-request [1]. But I also want to ask about two possible exceptions to the spec, due to the nature of Derby:

  • Is it OK for the derby version to use real-time updates, even though spec says otherwise (see comment about editing state under 'Persistence'). The real-time updates during edit is part of Derby's model-view binding supporting the collaborative editing.
  • Is it OK for the Derby version to use single-click to edit, even though the spec says otherwise (see point 2 under 'Item', and 'Editing' section) as well as using contenteditable rather than an .edit class. Again, this is more in the nature of derby to allow editing the actual model content, rather than bringing forward an input with a copy of the model's title. Double-click to edit seems to imply that update happens on blur. That said, I can change to double click if it's prefered.

Thanks!
-Michael

[1] Remaining todos before submitting pull request for https://github.com/absoludity/todomvc/tree/derbyjs, in case anyone else wants to jump in :)

  • Update the 'Created by you' to include our names (@lackac and myself)
  • flatten commits
  • Add ie.js
  • Tab indentation
  • Check quotes etc.
  • Add '.selected' class to filters (active, completed etc.)
  • Fix reload when filter selected (relative style path issue)
  • Clear the "Select All" state during "clear completed"
  • Hide an items controls (complete/delete) while editing, and still use edit class and ensure nice border around complete item, rather than the current contenteditable border.
  • Destroy todo if edited to empty.
  • Pluralise the item(s) counter.
  • Switch makefile to do all 3 steps in one (npm install, compile, run server)
  • Add the connectionAlert component
  • Check with derby folk whether there's a better way to do the filtering while still using a route.
  • Check why Firefox (at least on Ubuntu) doesn't display correctly (either do any of the TodoMVC apps that I've tried - so related to the theme).
Nate Smith
Michael Nelson

Thanks Nate. I'll try to get the remaining functionality done before the weekend then, so you can focus on pointing out better ways of doing things. I don't think there are any other (known) issues other than the ie < 10 support?

Sindre Sorhus
Owner

@absoludity :smiley:

Is it OK for the derby version to use real-time updates, even though spec says otherwise (see comment about editing state under 'Persistence'). The real-time updates during edit is part of Derby's model-view binding supporting the collaborative editing.

Yes, of course. The spec doesn't yet account for these types of frameworks. The comment was meant to prevent authors from persisting the editing mode "editing: true" in localStorage.

Is it OK for the Derby version to use single-click to edit, even though the spec says otherwise (see point 2 under 'Item', and 'Editing' section) as well as using contenteditable rather than an .edit class. Again, this is more in the nature of derby to allow editing the actual model content, rather than bringing forward an input with a copy of the model's title. Double-click to edit seems to imply that update happens on blur. That said, I can change to double click if it's prefered.

I've experimented with using the contentEditable before, but I found it to be an utter mess, so we didn't go forward with it. Not sure if this has changed the past year.

I'm not sure how useful it is to see the editing in real-time. Our Meteor app works just fine with the double-click method, and sends the change on blur. Though, this is all new, so please educate me.

@nateps @addyosmani Thoughts?

Addy Osmani
Owner

@absoludity @nateps

Real-time frameworks account for the next wave of application frameworks we would like this project to cover. As such there are a number of considerations our current specs don't account for and real-time updates are more than acceptable. In fact, as a user I would prefer to be able to see as much as possible during collaborative real-time editing.

Don't be afraid to show off the best your framework has to offer. At present, the Meteor apps functions fine without real-time editing, but I'd be happy for us to entertain a review of ideas you may have for better demonstrating real-time. As long as it covers what a typical Derby user would likely do, it's worth looking at.

I would second @sindresorhus's thoughts about contentEditable. In my/our experience, getting it working cross-browser, even if we're talking about modern browsers and in a way that still allows it to be easily compared to our other implementations can be a challenge. If its possible to avoid it for now that would be great.

Thanks again for taking the time to contribute an app to the project :)

Michael Nelson

@addyosmani @sindresorhus Great, so I've left the real-time editing (yay), but switched to use inputs that are always visible, instead of the contenteditable spans. This meant adding some input:focus style, but has the added benefit of being very accessible! Here's 30 seconds editing the todo list without a mouse (nor extra code). Thanks!

Edit: Note, I still need to hide the controls while the text is being edited... Tonight :)

Sindre Sorhus
Owner

Watched the video. Looks great!

Addy Osmani
Owner

Great work! I like it :)

Michael Nelson

I've fixed all the outstanding points I was missing from the spec - except the ie support as per @nateps 's comment above, squashed the commits and created a pull request at:

#261

Thanks!

Sindre Sorhus
Owner

Closing as Derby was added a while back.

Sindre Sorhus sindresorhus closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.