Add Derby.js #141

Closed
addyosmani opened this Issue Apr 20, 2012 · 24 comments

Projects

None yet

5 participants

@addyosmani
Member

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
nateps commented Apr 20, 2012

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
Member

Looks very interesting! Reminds me of Meteor.

@addyosmani
Member

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

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

@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
lackac commented Jun 13, 2012

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

@sindresorhus
Member

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

@sindresorhus
Member

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

@addyosmani
Member

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
lackac commented Jul 4, 2012

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
Member

Moving this to 1.1

@sindresorhus
Member

@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
lackac commented Aug 2, 2012

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
Member

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
nateps commented Aug 9, 2012

Hey Michael,

Thanks so much for diving into this! Looking great and the demo video is
clutch.

Going to be really hammered today and tomorrow, but I'll try and help point
you in the right direction with some of these issues over the weekend.

Note that Derby doesn't support IE <10 right now, and adding IE support
will take a good bit of work. @rma4ok has started to look into this and I
know how to do all of the required fixes, but there is a lot of work to do
there.

  • Nate

On Wed, Aug 8, 2012 at 11:59 PM, Michael Nelson notifications@github.comwrote:

Hi! I've had some time during the evenings this week, and have implemented
all the main functionality. I've done a 2 minute demohttp://youtu.be/akMqTuiYn0gwhich 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 have 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, in case anyone else
wants to jump in :)

  • Update the 'Created by you' to include our names (@lackachttps://github.com/lackacand 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).


    Reply to this email directly or view it on GitHubhttps://github.com/addyosmani/todomvc/issues/141#issuecomment-7606801.

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

@absoludity 😃

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
Member

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

Watched the video. Looks great!

@addyosmani
Member

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
Member

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