div1 = document.getElementsByTagName('div')[0];
div2 = document.getElementsByTagName('div')[1];

[div1].subtract([div2]);
/* should return [div1] */
/* returns [] */

[div1].union([div2]);
/* should return [div1, div2] */
/* returns [div1] */

[div1].intersect([div2]);
/* should return [] */
/* returns [div1] */

var setProp = function (obj, path, val) {
    path = path.split('.');

    for (var i = 0, max = path.length - 1; i < max; i += 1) {
        obj = obj[path[i]] = obj[path[i]] || {};
    }

    obj[path[i]] = val;
};

var getProp = function (obj, path) {
    path = path.split('.');

    for (var i = 0, max = path.length; i < max; i += 1) {
        obj = obj[path[i]];
    }

    return obj;
};

Which (when extending Object) would let us do:

var obj = {};
Object.setProp(obj, 'location.address.street', 'test');
console.log(obj.location.address.street); // -> test

And retrieve it dynamically with this:

console.log(Object.getProp(obj, 'location.address.street')); // -> test

I‘ve discovered that String.assign performance is subotimal for complex templates.

var s = '{x}  {y} '+('{yy}').repeat(1000)+' {x} {z}',
a = {x:"123",y:[5,6],z:3,yy:1},
t = Date.now(); 
for(var i=0;i<10000;i++) s.assign(a);
console.log(Date.now()-t);

runs about 4 seconds.

If we change an approach from in-place handling of each {smth} match to pre-generating regexps for each key in data obj, we can gain about 10x performance boost for an example given. Code

function assign(str, obj){
    var keys = Object.keys(obj), i=0, acc;
    if (keys.length>100) return str.assign(obj);
    for (acc=str;i<keys.length;i++) 
        acc = acc.replace(new RegExp('\\{'+RegExp.escape(keys[i])+'\\}','g'), obj[keys[i]]);
    return acc;
}
t = Date.now(); 
for(var i=0;i<10000;i++) assign(s,a);
console.log(Date.now()-t);

runs about half a second.

Although for small templates this approach is bit slower.

If Sugar.js used a wrapper around an object instead of modifying it I think it would give a lot of advantages.

One being that you can use it with other libraries with the same functionalities. If all these modify the native objects we would have a nightmare knowing which one is currently used.

Another being that you know what methods are from Sugar. So if you want to use another library in the future you can just search for s() eg. in s(object).clone().

I think many people will avoid using Sugar since it's extending the native objects directly thus making it less popular than Underscore.

The gist of this one is that dates relative to the current date such as 1 week ago as well as Date.past('4pm') (which creates the current date internally to enforce the past requirement that the method name suggests) are making comparisons to a new Date. When attempting to simulate working in different timezones it's sometimes required to offset the date in question before making comparisons, so allow a global timezone offset that will be used internally if set.

Currently going with Date.SugarTimezoneOffset

This value will be in minutes, same as returned by the native getTimezoneOffset...

---- ASIDE ----

One potential problem that I was also thinking about here was DST (daylight savings time). I was toying with the idea of allowing SugarTimezoneOffset to be a function that could manipulate the newly created date, but I don't think that would address the issue that was raised. As SugarTimezoneOffset will always be an offset for newly created dates, it can be manipulated dynamically (say if you really needed precision, you could set an interval watching for the traversal into a new day and reset SugarTimezoneOffset appropriately).

The issue that was raised was instead if you have Date.create('2 weeks ago'), if that date traverses a DST threshold, then it may in fact not be 2 weeks ago... however this issue is independent of the one above as it is also a "problem" for local dates that don't have an offset at all to begin with. I put "problem" in quotes as I don't know if it actually is an issue as technically a date 2 weeks ago that (for example) shows a 1 hour discrepancy technically is 2 weeks ago by the strict definition of 2 * 7 * 24 * 60 * 60 * 1000, therefore I think it would be incorrect to mess with the date in an attempt to correct it. Instead, the developer should adjust it accordingly as necessary for the given app/context.

There are many applications in which a user can be expected to input a date that must be in the future or must be in the past. Sugar's Date.create() mechanism is powerful but doesn't seem to expose a way for the programmer to hint the user's future or past intention if it is known. This limits its utility. In these cases, the user is required what seems to be redundant information. For instance, if I'm scheduling an appointment I should only need to say '4 hours' rather than 'in 4 hours'. Likewise, if I say 'Tuesday' or 'January' I'd expect to get the closest match in the future and rather than having to say 'next Tuesday' or 'next January'. It's possible for a user of the library to work around this by adding prefix/postfix hints to the user input, but this solution isn't portable and can go wrong in unexpected ways. (As an example, try passing the string 'feb of next month' to Date.create())

Let's say I want to make an array of five random numbers. Having used underscore, my first instinct will be to do this:

var arr = (5).times(function() { return Number.random(50, 100); });

But this won't work; it'll uselessly kick back 5. So this method lets you do something five times, and then continue chaining the number. I'm not sure why anyone would want to do that. If you want to preserve this behavior, why not return an array of the returned values if the function it calls returns something?

Right now I have 200K+ sloc js codebase built on top of Sugar 1.4.x. This code is running in production for 260К+ users. And this code use Object.merge and Object.clone extensively.

Changes made in these methods in 1.5 surely lead me – if I wanted to use them – to rewrite, not just refactor, all the code. Also we’ll need to retest it thoroughly.

Cost of these ops is absolutely enormous.

So there are three options for me in this situation if I want to use Sugar in versions 1.5+:

• ask Andrew to rethink
• ask to add backward-compatible aliases
• fork Sugar

May be I’m too late, but I think deep backward incompatibility is a serious issue worth to discuss.

Also I think there is no reason to remove String.has – it has clean unique syntax and is shorter than .contains. I see no conflict if .has coexisted with .contains.

What do you think?

Hi - The website's customize page let's me download only certain components that I am interested in. However, the downloaded files seem to be missing some variables causing the app to crash.

Has anyone used this? FWIW, i tried doing "all" from the customize page and even that is not loadable

Sugar seems to advance the date rather than rewind it when asking for a UTC version

Date.create().beginningOfMonth().toUTC()

Returns Wed Aug 01 2012 04:00:00 GMT-0400 (EDT)

This is the beginning of the month with our offset (-4) subtracted from the date. (This is actually what the docs say it will do, but it is wrong). We are behind UTC and therefore should have a Jul 31 date.

Compare this to moment.js

moment.utc().startOf('month').toDate()

Returns Tue Jul 31 2012 20:00:00 GMT-0400 (EDT) which is correct.

String#truncate didn't provide the functionality I needed, as such String#shorten has been added. The use case for the method is primarily URLs, where the beginning and end are more important than the middle. As such shorten defaults to truncating the string in the middle and including the length of the splitter in the length required.

"https://www.google.co.uk/search?sourceid=chrome&ie=UTF-8&q=sugar+js".shorten(45)
-> "https://www.google.co...e&ie=UTF-8&q=sugar+js"

Performs similar to String#truncate in that custom splitters can be included, as well as allowing the resultant string's length to omit the length of the splitter. The splitter can also be positioned at the left, right or middle of the string.

Array#punctuate builds a grammatical list from the array, taking a fn handler to deal with deep arrays. I've been working with long calling patterns for train services and this addition to Sugar help me deal with the headache. The trailing only on single length lists can be omitted too.

['Apples', 'Grapes', 'Bears'].punctuate()   -> 'Apples, Grapes and Bears';
[{type:'Apple', n:2}, {type:'Grape', n:1}, {type:'Bears', n:10}].punctuate(function(item) {
    var name = (item.n == 1) ? item.type.singularize() : item.type.pluralize();
    return item.n.toString() + " " + name;
})                              -> '2 Apples, 1 Grape and 10 Bears';

Extensive unit testing added for both methods. Tested in Node.js v0.6.14 and Safari 5.1.5 (Snow Leopard). Unable to use unit_test/../sugar.html in Chrome 18.x as XMLHttpRequest won't load local files because of Access-Control-Allow-Origin. Unsure if this is a know issue. The actual unit tests were ran independently and succeeded in Chrome.

Example date string (from MacOS localisation settings): Saturday, 2 May 2015 at 23.52.26

This gives an Invalid Date, while 'Saturday, 2 May 2015 at 23:52:26' works fine.

I feel that dots in time format is a common format and should be supported.

This fallback logic seems to be adding the tzOffset when it should be subtracting. At least, that would give a more consistent result. There may be some purpose for adding the tzOffset, but I'm not sure what that is.

The following examples are in the EDT (-04:00) time zone. The expected behavior is for the second and third results to match.

Chrome

new Date('10 20 2021 08:00').toISOString()
// 2021-10-20T12:00:00.000Z

Date.create('10 20 2021 08:00', { fromUTC: true }).toISOString()
// 2021-10-20T16:00:00.000Z
// Adds four hours instead of subtracting four hours.

Date.create('10.20.2021 08:00', { fromUTC: true }).toISOString()
// 2021-10-20T08:00:00.000Z
// Sugar's native fromUTC parsing results in a toISOString that matches the input.

Safari

This is just to prove we're falling back to browser-specific parsing.

new Date('10 20 2021 08:00')
// Invalid Date

Date.create('10 20 2021 08:00', { fromUTC: true })
// Invalid Date

Date.create('10.20.2021 08:00', { fromUTC: true }).toISOString()
// 2021-10-20T08:00:00.000Z

Testing on the latest version (in console at: https://sugarjs.com/dates/), I notice that this string fails to be parsed: mié, 25 ago. 2021 16:19

However, this, string succeeds: 25 ago. 2021 16:19

Any insight into this? I'm able to do some string cleaning if needed :)

Hi! I have tried the Date.create function with severals date patterns and it works perfectly but I found that it only works if the string only includes the date. If the string has other parts before/after the date, it fails. I think the problem is the way the format RegEx are built: https://github.com/andrewplummer/Sugar/blob/3ca57818332473b601434001ac1445552d7753ff/lib/date.js#L2297 I want to be able to parse a date from the string "New York, 22 August" the same way as from the string "22 August". Is there a way to solve my problem with Sugar?

Thank you in advance.

When you format a number that would be expressed using exponential notation by javascript and the base has a decimal part the decimals and the exponent is prepended to the original number.

Sugar.Number.format(10000000000000000000000, 2) => "1e+22" which is expected, but Sugar.Number.format(12000000000000000000000, 2) => "1.2e+22.2e+22" should just be "1.2e+22"