Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript Views, the Hard Way – A Pattern for Writing UI

github.com

Post reply on HN
Print view View original

131–140 of 141 posts

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#131

Post by iamsaitam »

AmalgatedAmoeba wrote: post #95
iamsaitam wrote: post #90

Earlier quoted context omitted.

"I can also ditch a database and just dump everything into a text file." <- This is what you're saying. It isn't hard to see the problem with this kind of thing.

ngl, a lot of the times, an in-memory “database” that gets backed up to a file is perfectly reasonable. Even consumer devices have dozens of gigabytes of RAM. What percentile of applications needs more? Just because a technology works well for a few cases shouldn’t mean it’s the default. What’s the 80% solution is much more interesting IMO.

There's absolutely no problem with this. But it probably shouldn't be a best practice or default for the industry? That's what op was saying. I'd argue you're still better off using SQLite than doing it manually, but to each its own.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#132

Post by chrismorgan »

naasking wrote: post #122
chrismorgan wrote: post #78

Earlier quoted context omitted.

Although appealing, that’s an extremely bad idea, when you’re limited to JavaScript. In a language with a better type system, it can be only a very bad idea. The problem is that different contexts have different escaping rules. It’s not possible to give a one-size-fits-all answer from the server side. It has to be done in a context-aware way. Field A is plain text. Someone enters the value “Alpha & Beta”. Now, what d…

You're unnecessarily complicating this. The server is aware of what fields are HTML so it just encodes the data that it returns like we've been doing for 30 years now. If your point is that this approach is only good with servers that you trust, then that's useful to point out, although we kind of already are vulnerable to server data.

You’re not getting it: we’re not talking about the server producing templated HTML, which is fine; but rather the server producing JSON, and then the client dropping strings from that object directly into serialised HTML. That’s a problem, because the only way to be safe is to entity-encode everything, but then when you use a string in a context that doesn’t use HTML syntax, you’ll get the wrong result.

It’s not an unnecessary complication. You fundamentally need to know what format you’re embedding something into, in order to encode it, and the server can’t know that.

Depending on what you do, you may want it unencoded, encoded for HTML data or double-quoted attribute value state (& → &amp;, These encodings are incompatible, therefore it’s impossible for the server to just choose one and have it work everywhere.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#133

Post by zdragnar »

chrismorgan wrote: post #127
zdragnar wrote: post #121

Earlier quoted context omitted.

Don't forget that different clients or view formats (apps, export to CSV, etc) all have their own sanitization requirements. Sanitize at your boundaries. Data going to SQL? Apply SQL specific sanitization. Data going to Mongo? Same. HTML, JSON, markdown, CSV? Apply the view specific sanitizing on the way. The key difference is that, if you deploy a JSON API that is view agnostic, that the client now needs to apply th…

Please don’t use the word sanitising for what you seem to be describing: it’s a term more commonly used to mean filtering out undesirable parts. Encoding for a particular serialised format is a completely different, and lossless, thing. You can call it escaping or encoding.

Sanitizing is just a form of encoding that prevents data from becoming executable unintentionally.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#134

Post by chrismorgan »

zdragnar wrote: post #133
chrismorgan wrote: post #127

Earlier quoted context omitted.

Please don’t use the word sanitising for what you seem to be describing: it’s a term more commonly used to mean filtering out undesirable parts. Encoding for a particular serialised format is a completely different, and lossless, thing. You can call it escaping or encoding.

Sanitizing is just a form of encoding that prevents data from becoming executable unintentionally.

I don’t like how you’re categorising things. Sanitising is absolutely nothing to do with encoding. You can sanitise without encoding, you can encode without sanitising, or you can do both in sequence; and all of these combinations are reasonable and common, in different situations. And sanitising may operate on serialised HTML (risky), or on an HTML tree (both easier and safer).

Saying sanitising is a form of encoding is even less accurate than saying that a paint-mixing stick is a type of paint brush. You can mix paint without painting it, and you can paint without mixing it first.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#135

Post by afiori »

austin-cheney wrote: post #86
alternatex wrote: post #77

Earlier quoted context omitted.

I feel like you completely misinterpreted their comment. They replied to a comment saying that state should not be centralized. They said that if the state decentralized (as in held by individual child components) it's difficult to coordinate between sibling and parent/child components. It seems like you're saying that it's easy to do UI with a centralized state, therefore agreeing with them whilst having the tone of…

The parent comment said: This approach is simple but does not scale and You need separation between components and data. That is garbage and is what I replied to. I completely understand why JavaScript developers would fail to read this as such as most JavaScript developers are wholly incapable of programming, a forest for the trees problem.

But centralised state is "separation between components and data"

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#136

Post by ChiperSoft »

dsego wrote: post #24

This reminds me of the venerable backbone js library. https://backbonejs.org/#View There is also a github repo that has examples of MVC patterns adapted to the web platform. https://github.com/madhadron/mvc_for_the_web

I would love to see a new take on backbone in the modern web without any jQuery integration. I genuinely miss how easy and powerful backbone views are.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#137

Post by austin-cheney »

nsonha wrote: post #126
austin-cheney wrote: post #86

Earlier quoted context omitted.

The parent comment said: This approach is simple but does not scale and You need separation between components and data. That is garbage and is what I replied to. I completely understand why JavaScript developers would fail to read this as such as most JavaScript developers are wholly incapable of programming, a forest for the trees problem.

> JavaScript developers would fail to read this > You need separation between components and data this is an universal way to do UI, in fact only javascript developers (out of curiosity, are you one?) would even argue against it, because "use the platform", vanila, simple... blabla, or you know, "incapable of programming" and thinking in terms of data flow as opposed to platform intricacies

The worst part about working in JavaScript is the insecurity. Everybody likes to act like they know what they are doing, but very few people really do. So, for most people its entirely a game to remain employed when they probably aren't qualified to be there in the first place. Its like musical chairs where everybody hopes when the music stops its the next guy left standing.

For the few people who do know what they are doing its an impossible situation. People simultaneously expect magic from you, because they know you can do it, but at the same bitch and cry about the output. They know they cannot write original code or extend somebody else's original solution so they demonize it out of self-preservation. When people are universally that insecure its convenient to hate on that one person who doesn't share that insecurity.

That is why I switched careers. I have never seen a salary high enough to justify going back to that.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#138

Post by motorest »

jdsleppy wrote: post #74
SkiFire13 wrote: post #56

Earlier quoted context omitted.

> use the DOM element value/textContent/checked/etc as the only source of truth How do you manage redundant state? For example a list with a "select all" button, then the state "all selected"/"some selected"/"none selected" would be duplicated between the "select all" button and the list of elements to select. This is the fundamental (hard) problem that state management needs to solve, and your proposal (along with t…

They could always fall back to storing a value in a hidden element in the worst case. All/some/none selected is often done with an indeterminate state checkbox https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... that can represent all three states. Maybe I don't understand the problem you are talking about.

> They could always fall back to storing a value in a hidden element in the worst case.

This approach sounds like it's desperately trying to shove a square peg through a round hole. Why would anyone choose to use an element, hidden or not, to store a value as an alternative to use a very pedestrian JavaScript variable?

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#139

Post by naasking »

chrismorgan wrote: post #132
naasking wrote: post #122

Earlier quoted context omitted.

You're unnecessarily complicating this. The server is aware of what fields are HTML so it just encodes the data that it returns like we've been doing for 30 years now. If your point is that this approach is only good with servers that you trust, then that's useful to point out, although we kind of already are vulnerable to server data.

You’re not getting it: we’re not talking about the server producing templated HTML, which is fine; but rather the server producing JSON, and then the client dropping strings from that object directly into serialised HTML. That’s a problem, because the only way to be safe is to entity-encode everything , but then when you use a string in a context that doesn’t use HTML syntax, you’ll get the wrong result. It’s not an…

> It’s not an unnecessary complication. You fundamentally need to know what format you’re embedding something into, in order to encode it, and the server can’t know that.

There are two cases here:

1. Backend endpoints are specifically tied to the view being generated (returns viewmodels), in which case the server knows what the client is rendering and can encode it. This frankly should be the default approach because it minimizes network traffic and roundtrips. The original code displayed is perfectly fine in this case.

2. Endpoints are generic and the client assembles views by making multiple requests to various endpoints and takes on the responsibility that server-side frameworks used to do, including encoding.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#140

Post by simg »

nonethewiser wrote: post #100
_heimdall wrote: post #71

Earlier quoted context omitted.

Any code base lives or dies by how well it defines and then sticks to conventions. We can enforce it in different ways, or outsource the defining of convention to other tools and libraries, but we still have to use them consistently in the codebase. I think the OP here is basically proposing that the developer should be directly responsible for the conventions used. IMO that's not a bad thing, yes it means developers…

Using a framework like react constrains developers in a different way. React isnt simply a convention like the linked example.

react isn't a framework, it's a library.
Post reply on HN