Remove the utility methods built-in jsblocks. Leave that to lodash and underscore

[astoilkov]

jsvalue - the built-in utility methods in jsblocks are having more problems than solving ones. The best option is to remove the utility methods by default and release it as a separate library. Only if it becomes stable enough it could get part of some jsblocks built. It should be people decision by default which library to use. Also jsblocks will introduce integration with lodash and underscore by default so the same experience is achieved when using those libraries.

[Kanaye]

What needs to be done here?
I would move the jsvalue-built to a seperate grunt task so we could build it for testing but don't build it in the default tasks.
And I would make the 'mvc' build the default (replacing the blocks.js/blocks.min.js and remove the mvc folder).
Also I would move/reimplement some methods we currently require within jsblocks to jscore (e.g. blocks.toObject is currently required but implemented within jsvalue).

Offtopic:
@astoilkov I sent you some message at gitter last week. It looks like you aren't active at gitter. Please tell me if you have a prefered way to communicate.

[astoilkov]

Hi,

I would move the jsvalue-built to a seperate grunt task so we could build it for testing but don't build it in the default tasks.

Why we need that? Can't we move that to the jsvalue project?

The other things seems all we need to do. You could do this work in a separate branch and then we should ensure the next version release is not a patch.

Regarding the communication. Gitter is a little buggy so I don't like it much. I use email, facebook messenger, viber. You could choose one and we could connect there.

[Kanaye]

Hi 😄 ,

Why we need that? Can't we move that to the jsvalue project?

I mean the integration task (the once that currently built the blocks-source.js and blocks-query-data.js.

But we of course we can remove these steps complete until jsvalue gets stable enough (a long way but some of the features of jsvalue are awesome so I would love to integrate it again in the future).

I'll start a new branch no-value when I start to work on this.

Regarding communication: I'm neither using facebook nor viber so I guess I'll write you an email once I've thought about some other things some more 😄.

[astoilkov]

Ok. I understand now. When you start working on this we can figure out the details if needed.

[Kanaye]

I'm currently working on this and stumbled accross a hard-dependencie in the DataSource.js (or precisely here ).
We could:

1. reimplement the missing methods: size, at, isEmpty and each
2. make them a 'soft' dependencie so they would only exist when jsvalue is included once it's a separate lib (I plan on doing some integration so that value and blocks would not override them when they are both included in the same document)
3. remove them completely.

What do you think ?

[astoilkov]

I think we can remove them. They don't enough value to reimplement them and I don't like optionally adding methods.

[Kanaye]

I created a branch that's resolving this.
I mostly removed internal usage of jsvalue apis and just moved a few over to jscore.
Namely: blocks.toObject, blocks.flatten and blocks.pairs.

We are loosing a lot of functionality and comfort with this (e.g. no more collection.each()) but I that should be expected.

I didn't removed the other optional "integrations" (e.g. in observable.extend()) as they are documented to be only working with jsvalue and will come handy once jsvalue is a seperate lib.

All tests are passing and I tested server- and client-side rendering with a modified version of the shopping example.

In my opinion we should release at least one more 0.3.x version with jsvalue included and than merge this. (I'll rebase it then so we have a clean historie).

---

Edit:
I pushed the mentioned version of the shopping example in a separate branch over here.
It doesn't looks as nice as the version on the master because of the removal of the utility methods.
I didn't want to drop in some other library like lodash because it wasn#t that much and I don't like to use other libs in examples.

[astoilkov]

Ok. Everything sounds great.

Regarding the version release: I agree. Do you know how to do this or should I do it?

[Kanaye]

I can look into building a release.
I'm also planning to (or at least I'm think about) make travis build and publish releases (tagged commits on the master branch).
At least if you agree that it could be usefull.
But maybe I'm just a to big fan of automating stuff.

I'm currently working on a fix for #126 and I think I can fix it within the next week.
So I would wait with the next release until that's done.

[astoilkov]

Nice. I am a big fan of automating stuff too. However, can you describe a little more the idea you have about travis. It seems I am not familiar with it.