Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Add Derby.js #141

Closed
addyosmani opened this Issue · 24 comments

5 participants

@addyosmani
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

@nateps

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.

@sindresorhus

Looks very interesting! Reminds me of Meteor.

@addyosmani
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.

@sindresorhus
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!

@addyosmani
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 :)

@lackac

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

@sindresorhus

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

@sindresorhus
Owner

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

@addyosmani
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.

@lackac

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.

@sindresorhus

Moving this to 1.1

@sindresorhus
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.

@lackac

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?

@sindresorhus
Owner

Awesome!
No deadline, but sooner the better ;)

@absoludity

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).
@nateps
@absoludity

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?

@sindresorhus

@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?

@addyosmani
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 :)

@absoludity

@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 :)

@sindresorhus

Watched the video. Looks great!

@addyosmani
Owner

Great work! I like it :)

@absoludity

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!

@sindresorhus

Closing as Derby was added a while back.

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.