Ideas and Suggestions for CLNDR 2.0

[kylestetz]

clndr 2.0 is happening

I am going to start the process in March. No idea how long it will take, but the result will be a brand new version of clndr.js. Here are a few things I can be certain of:

• The new version will not be backwards-compatible and will feature a more semantic API
• The idea of a "month" will go away in favor of any interval of time, allowing you to make a one-day view, a one-week view, a one-year view, or anything in between.
• Moment and jQuery are here to stay as dependencies, but underscore can go away
• It will be thoroughly unit tested
• It should work on the server

I would love to hear from all of you: what do you think needs to be included in a new version? Are there pain points (aside from the custom intervals stuff) that you're experiencing?

This will be collaborative

See issue #136 ... If you have an interest in contributing to the new version, you are encouraged to participate in whatever capacity makes sense for you.

Thanks!

[steilerDev]

Make it mobile friendly! (I actually hacked css and js to enable some kind of mobile friendly view in the current version, but it is not optimal at all)

Unfortunately I am not that skilled in JS at all so I would not be useful during the development, but I am happy to test and integrate the library in my projects!

[kylestetz]

@steilerDev thanks for the suggestion— my thought was that binding on tap when tap is available would be a step in the right direction. What other aspects do you think need some attention for mobile? Since the views and CSS are user-provided, it's on the developer to write styles that work on a device.

[stuplum]

I think removing jquery as a dependency would be a good goal, I am looking at using version 1 in an angularjs project and whilst jquery plays nice with angular, its a dependency I don't really want. If much of the view layer is handled by the developer I'm not sure why jQuery is needed although I have not looked in depth at what is going on under the covers. I would build version 2 as modular as possible and provide a wrapper for people who want to use it with jquery, it should be useable by more people this way. In fact if you intend it to be useful on the server, jquery seems like a strange dependency to enforce.

Moment is a more than reasonable dependancy, and depending on how much of the api you use, lodash/underscore 'could' be reasonable, but I suspect it would be better to just borrow the implementation of some of the methods you would use within lodash.

[kylestetz]

@stuplum that's interesting. Dependencies are definitely a major complaint, but jQuery is the one I hear complaints about the least! I was going to look into stealing the _.template functionality so that underscore/lodash could go away. Moment, as you have pointed out, is here to stay.

There's a delicate balance here that we need to strike in v2.0. I do not under any circumstances want to be writing native DOM queries and monkey-patching fixes for random browsers, which is what jQuery allows us to avoid. Clndr should work out of the box down to ~IE7, and without jQuery this becomes complicated (and makes for a bloated codebase).

For reference, jQuery's main responsibilities are to handle click events and injection of the rendered template into the DOM.

My worry about supporting angular is that there is barely any overlap with the scope of clndr's functionality. Angular has its own concept of templating, events, and DOM manipulation. Literally the only thing you would want from clndr is the part that keeps track of the current date. My thought was that the architecture could be modular enough that you would be able to use this component separately, but correct me if I'm wrong in saying that 90% of clndr becomes unnecessary if you want it to play well in angular world.

I am really excited about figuring this out! I've had plenty of questions about angular integration so if we can make that less painful in the next version I think it's totally worth it.

[miljan-aleksic]

I have successfully implemented this simple template function into clndr by moving the js function from the template string to the render function as it does not support advanced logic statements (only if and foreach), but that's enough if the data is prepared before.

[kylestetz]

Awesome @miljan-aleksic, that's very encouraging.

[arvi]

I would really love to use this in a meteor app. However, I can't seem to make it work in meteor. I'm not sure if it's because of meteor's blaze templating or because of how the library was built with the checking if jquery or moment is defined... I'm a novice at this... but I hope this library is as easy as others to just package for meteor (https://atmospherejs.com/rzymek/fullcalendar). Already spent whole day trying to make it work...packaged or just an asset I can't figure it out. Oh boy.

[adrianmcli]

@arvi
I'm also trying to make this work in Meteor. I've spent at least 6 hours trying to make this work and it's quite frustrating. Simply applying spacebars does not work. There also seems to be no exposed variables for us to watch reactively. There does seem to be a daysArray variable that has leaked into the global namespace, but I think this is a bug. Nevertheless, it's not reliable because the moment date object gets corrupted whenever I try to set daysArray into my Session variable in Meteor.

At this point, unless someone more skilled can pitch in on the Meteor front, it might be best to use something else.

[stuplum]

I'm pretty sure the leaked daysArray is a bug as well. I have patched it locally whilst I'm building an angular directive around it.

[kylestetz]

Oof, first off, thanks for the heads up about the leaky daysArray variable, fixing that now.

I'm sorry to hear about your Meteor troubles. The modular architecture we have in mind for v2.0 aims to solve this problem. Unfortunately clndr was written as a jQuery plugin, and supporting myriad MVC frameworks was not an initial goal of the project.

What I need from you now is a sense of which piece of clndr you're looking to use. It seems like you're only interested in the daysArray that gets generated on load/each time clndr is advanced. Is that correct? If that is the case, are you aware that you can supply your own render function, which passes you the daysArray as data? Clndr's api allows you to advance it programmatically, meaning that you don't have to rely on DOM events— this opens you up to the possibility of working with your own template in a separate framework that is loosely coupled to clndr through its api. We can talk this through in a separate issue if it seems like a direction that will make sense for you all. I have never used Meteor, so feel free to tell me that I'm totally off on this one.

[kylestetz]

Further thoughts on this @arvi, @adrianmc or @stuplum? We are going to begin architectural planning for 2.0 on Monday. Did you figure out a solution to your Meteor/Angular issues or, if not, do you have ideas about what it should allow you to do?

[stuplum]

I've been spending most of my time around creating a tested/able directive for consuming clndr as it currently stands.

I am considering creating a patched version that removed the jquery dependency completely, as I don't think it will be required at all for angular. It will be interesting to see whats left when the view logic is removed and just the clndr module with an api is left. I am a bit reluctant to do it right now though as it works as is for me at the moment and I have other priorities, which is a shame as I'm itching to have a go.

I think the only 'issue' I have run into so far is with the month property on the data supplied to the render callback being a formatted month, whereas I would prefer it to just be a moment object that I can play with programatically. This is probably more of a preference than an issue.

I would potentially consider wrapping all of the moment objects into a clndr specific date object, but I guess this would only be important if you decided to ditch moment.

[arvi]

Hi Kyle. Unfortunately, I switched to using fullcalendar due to project's deadline. I think the issue is with Meteor's Blaze Templating since when I tried patterning CLNDR template to Blaze/Spacebar syntax http://meteorcapture.com/spacebars/, rendering does not work.

I hope the next version would be template-agnostic. :)

[kylestetz]

@stuplum I hear you about the formatted months. It would be my preference as well but at this point it's a big BC break to change it. Open to your ideas about what else should be passed into the template!

Can you elaborate on that last point about a clndr specific date object? I'm not sure I understand.

@arvi bummer. Did you see my note about the render function? Clndr is already template-agnostic.

[stuplum]

@kylestetz The clndr specific date object would be a wrapper class around any moment object. It would expose it's own methods and properties (that may or may not have the same interface as moment), but it would allow you to swap out moment for another library or even a custom implementation in the future. I guess it's only important if you were unsure if moment was going to hang around or not.

[kylestetz]

Ah, interesting. Moment is not going anywhere, but I'll keep this in mind as we plan the architecture and see if this might benefit us in some other way. Thanks!

[arvi]

@kylestetz Oh okay. Sorry, I missed reading that comment. I'll try it out and see if it'll work. :)

[kylestetz]

Following up on our discussions, you can read about the first steps toward the next version in #155. Development will be starting soon!

[krokofant]

Is CLNDR currently capable of carrying end-dates for events? This is one thing I'm missing for my day-view. I specifically want to be able to display the event duration.

I love your work. Awesome stuff!

[t2thec]

Just found CLNDR. Awesome.

You've mentioned the one-day option. This would be great for us (currently using fullcalendar). I presumably we would be able to style hours/mins etc so we can display a day schedule? Not just a list of events for a given day?

Also, we use resources a lot. I think we could code this currently? Not quite sure. Basically grouping events by a given value (name or room for example) and displaying events for each resource. An example ( this isn't very customisable in terms of templating. We prefer a vertical view) http://fullcalendar.io/scheduler/

Love the work dude. Cheers.

[yepeekai]

I think it would be great to design it to make it possible to do databinding for events. For example having an event "beforeRender" where I would be able to modify the events array. We use it for a lot of events and it doesn't make sense to load 5 years of events, it would be better to load them on demand.

Thanks

[kylestetz]

See #136 for an update on the status of clndr 2.0. We won't be pursuing a rewrite of the project for now, and instead we're cleaning up the codebase to ensure that this project continues to be maintainable and easy to contribute to!