JavaScript Components

[audionerd]

Some JavaScript features may not belong in spaceBase "core", but could be useful add-ons. Perhaps in a spaceBase-more repo?

A running list of possible modules we should standardize:

• custom triggers for google analytics tracking (via data-*)
• responsive carousel

What else?

We should document them briefly inline, and provide HTML demos. They should be easy to use as individual modules (perhaps via Bower?).

Not sure the best way to organize them, but I'm leaning toward Components with a bower.json.

But overall, I want to keep them simple. I like the approach taken by Bootstrap's JavaScript components, which have very small, simple classes, with wrappers for jQuery, and a Data API for each.

Make them good simple starting points and open to editing as necessary.

(I think I want them in CoffeeScript, though)

[athaeryn]

Sorry. -1 me

[audionerd]

More on "Components":

http://tjholowaychuk.com/post/27984551477/components http://dailyjs.com/2013/01/28/components/

[wfendler]

My preference is that none of the javascript defaults are in coffeescript. Adoption and understanding of CS isn't as high as Sass around here and I'd prefer not to introduce more dependencies. The last three projects I've been on have not used coffeescript. But I suppose there's always js2coffee to get the compiled JS..

I do agree though that analytics and a responsive carousel could be added. Flexslider is what we've used previously, but it had some pretty critical bugs in recent releases. @mckennedy added Owl Carousel on Pentair intranet, but we're only using it for a very simple, non-responsive purpose. So it'll be hard to say if that's worth sticking with or not.

@audionerd, you seem to be the only one around here using things like bower for components, so it might take some work to get the whole team in on that workflow. It seems like a really great thing, but just something to consider.. no one else that I've seen is doing that. Perhaps a little walkthrough/workshop soon?

[athaeryn]

I was going to open a similar issue last week, saying that Flexslider does not belong in spaceBase. I totally agree that we should have a separate collection of commonly-used js components for things like carousels, tracking, form validation, etc.

Also. CoffeeScript is "just JavaScript." It took me a few hours to just look over the syntax and then a couple days of using it to be comfortable with it. Yes, it's another thing to learn, but it's really nice. "CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way" and it does a terrific job.

Re: nobody using bower https://github.com/space150/spaceBase#installing-spacebase-with-bower :)

[wfendler]

Re: Spacebase with Bower: I don't think spacebase should be a bower component, it is made as a starting point for the front-end, not an independent "component". Maybe I'm misunderstanding what components actually are for, but it seems like spacebase is not one of them. It could be made up of components, but it itself is not one.

Forgive me if I'm incorrectly speaking on behalf of the rest of the department but I'm just hesitant to make coffeescript a default when only about a third of the department is at the level of fully understanding it, whereas 100% of the department understands Sass (hence that being a default).

[tjdunklee]

I'm with William that we shouldn't force people to use CoffeeScript by default. I may be wrong, but I thought part of the point of spaceBase was to have a nice simple platform to speed up front-end development. If this is the case, it seems like adding assumptions such as "the developer knows coffeescript" is a bad idea. Newer developers would probably stray away from using spaceBase because it will already be beyond their skill level. It seems to me like spaceBase already has a lengthy ramp-up time for a new developer, so let's not complicate it too much.

@athaeryn - I used spaceBase without Bower...

[athaeryn]

The Bower statement was a joke. :) Although I agree, I don't think that spaceBase itself should be a Bower component.

[audionerd]

I found that spaceBase is better as a scaffold (to be modified) than a pristine library (to be untouched). So yeah, spaceBase itself is probably not going to be installed in a project via Bower.

Re: CoffeeScript – what if we use CoffeeScript for components as spaceBase authors, but provide pre-compiled JavaScript for consumers?

So if you want to make use of spaceBase components, JavaScript is fine. If you want to modify spaceBase components, you'll have to use CoffeeScript.

I feel like most of the components should be powered by data attributes anyway – making their 80% use cases powered just through HTML.

[athaeryn]

If you heathens (:heart: you guys) don't want to learn CoffeeScript, then I think the approach @audionerd describes is a good one. That way, the eager young spaceBase cadet won't be exposed to CoffeeScript, but we can still take advantage of it in developing components.

[wfendler]

Yeah, I think I'd be down with that. A separate repo for each component as a bower component?

I just don't want spacebase to require coffeescript. Even better if I can just include a bower component for our analytics and just get the compiled JS, and not have to worry about the coffeescript source that it was authored in.

[audionerd]

@wfendler Sounds good. I think we should design for that in mind. It's a best practice to pre-compile bower-friendly components – we could automate that, so they're always up-to-date with every checkin, ready to bower install.

[athaeryn]

I'm okay with this. So are we going to have a separate repo for each bower component then? I think that makes sense from a development standpoint, so they all have their own history, issues, etc., but that could get to be a lot of private repos. So do we make them public, along with spaceBase? It would motivate us to get documentation in order, if nothing else. :)

[audionerd]

Good question. I'm leaning toward a single repo (spaceBace-more? or spaceBase-contrib?) just to get up-and-running.

I feel like it'll be used mostly for copy-and-paste.

Later, we can separate popular ones and add bower compatibility, etc.

[wfendler]

This is separate from current third-party/vendor libraries, correct? That should be started in a wiki in this repo.

[athaeryn]

I started a wiki page for that. https://github.com/space150/spaceBase/wiki/Suggested-Components

[athaeryn]

How about spaceBaseHanger?

[audionerd]

@wfendler right. In addition to the suggestion components doc, we'd have our own space150 JavaScript libraries, including some that may pair well with spaceBase.

[wfendler]

Closing this, assuming @audionerd or @cstoobes will create this new components repo. Any further discussion can happen there.