
A full port of LINQ for JavaScript - jeswin
https://github.com/Anstinus/lazy-linq
======
bigdubs
One of the C# language features that makes LINQ so powerful is expression tree
support; this allows the lambda (i.e. x => x * 2) to be read as a structured
object and turned into something else (such as sql).

This would be pretty useful in ES7 or whatever spec is coming down the road
for javascript.

~~~
bunderbunder
In practice, it ends up being _too_ powerful. The expression tree stuff tends
to mostly be useful when you're using the IQueryable<T> interface. If there's
a way to use IQueryable<T> to much effect without breaking encapsulation and
creating tight coupling, I haven't seen it.

~~~
Someone1234
When you're directly interacting with the database tight coupling is always
going to happen, and trying to hide that only adds needless complexity.

The nice part about using Linq and IQueryable instead of e.g. query strings,
is that the compiler (and intellisense) can check for some errors at compile-
time instead of run-time. Just have to make sure your database model is 1:1
with the actual database.

After you have the data you can throw it into a non-database DTO to re-couple
a bit and pass it between layers.

~~~
bunderbunder
If you're looking for compile time type checking, I'd say you should go one
further and just write your data access layer in F#. The SQL type provider
gives you much more thorough compile-time error checking than anything I've
seen in an ORM.

There are a couple different ways you can set it up to use the actual database
to do this, thereby eliminating the extra work of having to maintain two
different copies of your schema in two different languages, and making sure
they're kept in sync.

~~~
i_s
People tend to drop type providers in F# for non-trivial programs, because the
benefits need to be extreme in order to justify adding flakiness to the build.
Type providers also have the problem of yielding errors to people who may not
be in the best position to fix them. In a bigger team, it may be better to
have one part of the program be yield errors at runtime, but still compile, so
the team can keep on working until it is fixed. (The alternative of course
being code generation, which is triggered intentionally.)

~~~
akra
Disagree with this; because it very much depends on the program being written.
From what I've seen they've become more popular with ironically the exception
of the SQL ones for the reason you describe. As long as you can get the
schema/example file locally on the source tree without the type provider
needing to fetch it remotely it saves having to write up a lot of classes by
hand. E.g with web UI calls just get the swagger Json and download it into
your solution, for rest/json APIs just drop all the example documents into a
folder and have the type provider reference that. Once the source data is
local the flakiness mostly goes away and it just becomes a much quicker/less
error prone way of expressing schema from a wide variety of sources. It's
personally saved me a lot of time in development especially when interacting
with many data sources at the same time - that's a lot of Dtos I would have to
craft myself and I would in this case probably moved to a dynamic language a
while ago for the work I do. A type provider that allows local schema would
deal with your issue and then you would get type checked SQL queries at
compile time without the direct db dependency and connection latency.

~~~
i_s
If you only use it that way, type providers are only slightly more convenient
than doing what everyone already does for every other language: code
generation.

See quicktype, for example, which supports a lot of languages.

[https://quicktype.io/](https://quicktype.io/)

This isn't built in to the editor, but can be run from the command line. A
benefit is that it does not suffer from the other problems with type
providers, like not supporting the full language, (e.g., records and
discriminated unions in F#).

~~~
akra
Having 10 lines of code for 10 different data sources and having a explorable
Intellisense API for all of them is much nicer though than having 10 code
generator + command line tools in my now required build pipeline, each one
with a different syntax. Don't get me wrong - I will resort to code generation
for some things if there isn't a type provider available but I always find
more friction with this path and still doesn't give me all the benefits of
type providers (e.g the SQL static type checking aspect). It works across
different IDE's, don't need to introduce more build tooling, generated code is
obvious vs a code generator, is as cross-platform as the underlying
language/runtime is, etc.

Slightly more convenient for one source becomes very convenient as the amount
of data your analyzing increases. It's not the be-all-end-all it was promised
to be as a feature but it is easier than code generation IMO. If you can get
rid of the disadvantages by keeping reference schema locally in its native
form (e.g no flakiness you mention) then why not use it?

~~~
i_s
Fair points. I consider the lack of support for the good F# features like
records and DU to be an extremely big downside. I think we agree on the facts,
just weigh the costs and benefits differently.

------
sebazzz
Too bad this project does not supply Typescript typings. LINQ works best
together with strong typed programming model.

------
tehlike
Not to steal attention, but i found this:
[https://github.com/mihaifm/linq](https://github.com/mihaifm/linq) and have
been using this for quite a while now.

~~~
WorldMaker
There's also IxJS:
[https://github.com/ReactiveX/IxJS](https://github.com/ReactiveX/IxJS)

It additionally has the benefits of ESNext (Stage 3) AsyncIterable support,
and some synergy with RxJS.

------
Shoothe
I wonder why the examples do not use arrow functions. That'd make them more
readable IMHO.

------
flavio81
This is great stuff! Thanks for this project!

------
manojlds
Any reason to use this over lodash and such?

------
whitten
Could someone explain what the word "transpired" means in the context of the
README ?

~~~
styfle
[https://github.com/Anstinus/lazy-
linq/pull/1](https://github.com/Anstinus/lazy-linq/pull/1)

