Discuss introducing Path Syntax

[jhusain]

@trxcllnt @michaelbpaulson @ktrott @sdesai

I still think we should have this in place before open-sourcing. The Path Syntax is to Falcor as JSX is to React. JSX is just a thin wrapper for JSON objects. FB wisely understood when you're introducing people to vastly different technologies, you want to give them all the familiar touchpoints you can.

Can we cost this work out? I'd be surprised if it was more than three days. I think we should just push the release date to get it in.

[ktrott]

The difference is there is no performance penalty with JSX as its factored out at build time.

On Apr 8, 2015, at 4:19 PM, jhusain notifications@github.com wrote:

@trxcllnt https://github.com/trxcllnt @michaelbpaulson https://github.com/michaelbpaulson @ktrott https://github.com/ktrott

I still think we should have this in place before open-sourcing. The Path Syntax is to Falcor as JSX is to React. JSX is just a thin wrapper for JSON objects. FB wisely understood when you're introducing people to vastly different technologies, you want to give them all the familiar touchpoints you can.

Can we cost this work out? I'd be surprised if it was more than three days. I think we should just push the release date to get it in.

— Reply to this email directly or view it on GitHub https://github.com/Netflix/falcor/issues/67.

[jhusain]

Perf penalty is the least compelling argument against the path syntax. This is just Big O notation. The O here is a number smaller than 5 in practice. The parse only applies to paths that are entered explicitly by a human being (ie < 3). If there is any question of perf they can always use Paths explicitly. Remember by the time they're worried about performance, they are already invested and have learned Falcor. They are unlikely to ditch the framework, especially when there is a workaround available. This feature is about getting people over the hump.

JH

On Apr 8, 2015, at 4:34 PM, Kim Trott notifications@github.com wrote:

The difference is there is no performance penalty with JSX as its factored out at build time.

On Apr 8, 2015, at 4:19 PM, jhusain notifications@github.com wrote:

@trxcllnt https://github.com/trxcllnt @michaelbpaulson https://github.com/michaelbpaulson @ktrott https://github.com/ktrott

I still think we should have this in place before open-sourcing. The Path Syntax is to Falcor as JSX is to React. JSX is just a thin wrapper for JSON objects. FB wisely understood when you're introducing people to vastly different technologies, you want to give them all the familiar touchpoints you can.

Can we cost this work out? I'd be surprised if it was more than three days. I think we should just push the release date to get it in.

— Reply to this email directly or view it on GitHub https://github.com/Netflix/falcor/issues/67. — Reply to this email directly or view it on GitHub.

[ktrott]

Agreed it is not my main argument. I was just responding to your JSX analogy specifically.

My real concern is that it will be confusing from a usability and debugging perspective: what goes in, is not what comes out. It feels to me like almost immediately people will have to learn the real path syntax (array). You can't write the server response in this way.

I'm not going to lay on the tracks over this one, but I think it does distract from our goals: not needed for inner source and takes longer to open source.

Willing to be convinced or hear otherwise.

On Apr 8, 2015, at 6:05 PM, jhusain notifications@github.com wrote:

Perf penalty is the least compelling argument against the path syntax. This is just Big O notation. The O here is a number smaller than 5 in practice. The parse only applies to paths that are entered explicitly by a human being (ie < 3). If there is any question of perf they can always use Paths explicitly. Remember by the time they're worried about performance, they are already invested and have learned Falcor. They are unlikely to ditch the framework, especially when there is a workaround available. This feature is about getting people over the hump.

JH

On Apr 8, 2015, at 4:34 PM, Kim Trott notifications@github.com wrote:

The difference is there is no performance penalty with JSX as its factored out at build time.

On Apr 8, 2015, at 4:19 PM, jhusain notifications@github.com wrote:

@trxcllnt https://github.com/trxcllnt @michaelbpaulson https://github.com/michaelbpaulson @ktrott https://github.com/ktrott

I still think we should have this in place before open-sourcing. The Path Syntax is to Falcor as JSX is to React. JSX is just a thin wrapper for JSON objects. FB wisely understood when you're introducing people to vastly different technologies, you want to give them all the familiar touchpoints you can.

Can we cost this work out? I'd be surprised if it was more than three days. I think we should just push the release date to get it in.

— Reply to this email directly or view it on GitHub https://github.com/Netflix/falcor/issues/67. — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/Netflix/falcor/issues/67#issuecomment-91082323.

[sdesai]

My main concern was that we're introducing 2 ways for users to define paths when using the library, based on the fact that the existing syntax was not instantly grokable in a presentation/slide context (like the selectSwitch, or flatMapLatest, or switchMap confusion, trying to make everyone happy).

I feel that in the context of a novice user trying to understand Falcor by going through the README (or whatever final introductory material we decide on - a context which I think is significantly different from a presentation), the current syntax would not be a barrier to entry which was significant enough to warrant a 2nd syntax.

My list of cons for the 2nd syntax:

a. A decision for the end-user, when using the library (which one do I use? based on what criteria?). b. Additional maintenance (testing, development, documentation, communication). c. An additional performance cost (may be insignificant, but when we're scraping to get everything we can on constrained devices, it's worth justifying the need for it).

For me, the decision centers around "Is the learning curve significant enough to warrant the sum of the above 3 costs. Are we sure it's not a knee-jerk reaction to the feedback in a presentation context".

I'll let Jafar fill in his counter points based on a hallway conversation (rather than put words in his mouth).

[sdesai]

BTW, Jafar, to the point about the current syntax leading people to try this:

['lolomo', 0, 0, ['summary', ['item', 'summary']]]

I can see folks trying to do the same thing with the new syntax:

"lolomo[0][0]['summary', 'item.summary']"

As soon as they know they can do:

"lolomo[0][0]['summary', 'evidence']"

So, that argument cancels itself out in my head, unless I'm missing something.

[jhusain]

Although there is an equivalence here, I don't think the same hazard exist. JavaScript has never allowed paths within indexers, and all strings within indexers are evaluated as single keys. JavaScript developers have no reason to assume otherwise here. If the outer path was nested in an array, I could see this confusion arising. This is what happens with paths today and because developers are unsure of the grammatical rules within this new construct we get confusion. If they start out with the model that it's just JavaScript, I believe they will fall into the pit of success.

JH

On Apr 8, 2015, at 7:01 PM, Satyen Desai notifications@github.com wrote:

BTW, Jafar, to the point about the current syntax leading people to try this:

['lolomo', 0, 0, ['summary', ['item', 'summary']]]

I can see folks trying to do the same thing with the new syntax:

"lolomo[0][0]['summary', 'item.summary']"

As soon as they know they can do:

"lolomo[0][0]['summary', 'evidence']"

So, that argument cancels itself out in my head, unless I'm missing something.

— Reply to this email directly or view it on GitHub.

[ThePrimeagen]

I have implemented all of the path syntax for the talk this thursday except for nested quotes. That is a lower pri item and not necessary for the talk. I created a ticket to track it.