andrewplummer/Sugar — Issue #83: Feature: String.pluralize(), String.singularize()
Author: inossidabile
Created: 2012-01-02 16:51:32+00:00
State: open

We are living in the age where JS-framework like Backbone/Spine/etc are capturing it's part of Web. Sugar.JS is clearly the best ever lib to use as a language support. All of those frameworks use REST to get data and to manipulate it. Moreover all of them use custom constructions to make better OOP in JS: something you usually call a "class".

If we look at what JS-models are we can see they don't differ from what we have at Rails/Django or anything else. And that's where inflection is a must-have.

Let's imagine we have something like "User". If I define "class User" in some framework-specific way, should I also mention "/users" url for it? And should I mention that it will be returned as "user: [...]" JSON (with 'user' as a root node)? Or should I just mention "single: user; plural: users" and go with defaults? In fact I should only give a right name to my model. And then I can take first one from model's name. But the second... That's where we get into the trouble.

We have such JS-framework under heavy development. It's based on two kits: CoffeeScript and Sugar.JS. It has model-like things we call resource. Here it is: https://github.com/roundlake/joosy-rails/blob/master/vendor/assets/javascripts/joosy/core/resource/rest.js.coffee. Line 59 is a great demonstration of where this methods could save us several line in each descendant.

We've solved this problem with inclusion of excellent port of Rails inflections which can be found here: http://code.google.com/p/inflection-js/ so I don't only ask for myself ;). In fact I have no doubt it has to be a part of Sugar.JS since such string modifiers are so native for modern DRY programming and dealing with any data providers. And for sure they are getting more and more required in modern rich JS development.

I understand it will take some more precious space when packaged but come on. You have quite a lot of methods in it which gonna have a little usage. Or even locale-specific. So it's probably not to be solved by not including important things but by splitting lib in parts (like we discussed on twitter) :)