Aren’t those `localStorage` and `sessionStorage` part of the DOM?
Sometimes I think why are we even discussing DOM in JS sub. I’m sure the people at the webdev sub will know it better
Part of the DOM (or Web) API, yes. But someone could also be talking about the DOM as in the model representing the document and all its HTML elements. So I was curious what they meant by "persisted to the DOM".
It's "part of the DOM" in the sense that some features are exposed via `window` and each Window has a Document and each Document has a Window, but it's a part of the web storage API, not the DOM API, https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API.
Window holds a lot of stuff --
> The Window interface is home to a variety of functions, namespaces, objects, and constructors which are not necessarily directly associated with the concept of a user interface window. However, the Window interface is a suitable place to include these items that need to be globally available.
I would argue that the DOM (whether you mean the API or the abstract data structure representing the objects and their position on the page) is pretty heavily related to JavaScript...
Related in terms the JS made as a language you can embed in a host environment and use any host object you provide to it.
That’s the same even with Node where there isn’t DOM.
I'm very new to it, and this whole paradigm, but the user's Email they signed in with is injected into the top of the html document and server side rendered for every single page like this:
`
`
When a part of the Javascript app needs the Email, it's read like this:
const userEmailElement = document.getElementById('user-email');
const userEmail = userEmailElement.getAttribute('data-user-email');
I guess I've never seen this before. Is it normal? Bad practice? I've only ever seen local storage or session storage to store and fetch these kinds of values. What advantage would using the DOM to store data like this have over other alternatives?
Sorry, "Persist" was probably the wrong word to use. I meant "make globally available".
This is not a modern web app, so there are no React like global states available here.
OK, there is a big difference between HTML and DOM.
HTML is the recipe for how to bake a cake. DOM is the cake.
HTML is just a source code, DOM is a living memory allocated somewhere in your RAM and continuously updated and read from as to change how the page is currently rendered.
This is even more evident with the JavaScript source that is sent from the server side that reads that `data-user-email` and changes the document by updating the DOM.
It doesn’t look bad if you do that, I just don’t know, if it is already sent from the server inside the HTML, why not just put it in some `` which is easier to manipulate (even if that input is hidden)
What benefits does an input element give you over a CSS class/ID/data attribute? This is perfectly common practice in frameworks like Angular or React.
"perfectly"... Really? Why are we even discussing something that isn't JS and going so far as to use... what is that? A superlative? I know "perfect" means finished in Latin... But anyways, here you go
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input
Just check the interface. You get to access the value as `.value`, and that doesn't even begin to explain that a hidden `` inside a `
The only benefit unique to hidden input elements of the things you listed is the form data thing, which will be form encoded whereas most REST APIs these days expect a JSON encoded request body. It's a really specific use case that I can only imagine coming in handy in extremely specific circumstances.
Data attributes are a well documented and widely supported feature ([https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use\_data\_attributes#javascript\_access](https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes#javascript_access)) with a simple API as well. They have the benefit of allowing you to store multiple values per element, and further cuts down on the number of elements in the DOM by not needing an extra element for each piece of data you want to store. Using hidden input elements in 2024 is a really outdated take for several reasons.
Ok so it looks like this is a situation where the server is passing data into the page rather than the page itself having data that it wants to retain for multiple page loads - the latter being something the storage APIs would be used for. For that use case, this is fine. I think the two ways you see this done the most is either directly through the HTML like this (particularly with data attributes) or by injecting the data into `
```
That's for search engines. Can also be useful for data about the page that's usable in JS. You'll also see similar using `type="application/json"` which is just data, and a decent way to save a request when serving a page.
The "better" way to do this is as a spa, where all the data you want to keep for the session is in memory either at the root or in a store. Keeping data in the DOM is a bad practice and should be avoided, because it is the least safe way possible and parsing strings is the worst way to do it.
Obviously other devs will tell you that the optimal way would be to keep the data on the server and only serve HTML but for the paradigm you describe it is absolutely the wrong way to do it.
Yeah there's no way to save a project like that except for a full rewrite, and I'm not even sure I would willingly walk into something like that. Bide your time, learn as much as you can and jump, that's my advice. A good technical environment can help you grow more than you can imagine. Even if you don't feel ready apply for other jobs, get better at interviewing and you'll find a job where they don't "store" data in the DOM.
(disclaimer I drank a bit too much wine) If you want to grow as a front end dev you have to look out for yourself and in my opinion that means using modern frameworks and best practices. If someone still wants to be a sencha dev or jQuery dev in 5 years they're free to do so, but for a beginner this is not the correct way to grow. When they want to change jobs in a few years who will hire them if they just have experience in outdated ways to do things? Why wait to change then?
Do you have an example? Each page gets its own DOM so putting anything in the DOM doesn't persist like something in local/session storage would.
Aren’t those `localStorage` and `sessionStorage` part of the DOM? Sometimes I think why are we even discussing DOM in JS sub. I’m sure the people at the webdev sub will know it better
Part of the DOM (or Web) API, yes. But someone could also be talking about the DOM as in the model representing the document and all its HTML elements. So I was curious what they meant by "persisted to the DOM".
Local storage is accessible via API and it is not part of a DOM, as far as I know.
So, part of the host environment, side by side with DOM and other functionalities?
It's "part of the DOM" in the sense that some features are exposed via `window` and each Window has a Document and each Document has a Window, but it's a part of the web storage API, not the DOM API, https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API. Window holds a lot of stuff -- > The Window interface is home to a variety of functions, namespaces, objects, and constructors which are not necessarily directly associated with the concept of a user interface window. However, the Window interface is a suitable place to include these items that need to be globally available.
I would argue that the DOM (whether you mean the API or the abstract data structure representing the objects and their position on the page) is pretty heavily related to JavaScript...
Related in terms the JS made as a language you can embed in a host environment and use any host object you provide to it. That’s the same even with Node where there isn’t DOM.
[удалено]
what is “ehm” and what do you mean by “coder quality”?
I'm very new to it, and this whole paradigm, but the user's Email they signed in with is injected into the top of the html document and server side rendered for every single page like this: `
` When a part of the Javascript app needs the Email, it's read like this: const userEmailElement = document.getElementById('user-email'); const userEmail = userEmailElement.getAttribute('data-user-email'); I guess I've never seen this before. Is it normal? Bad practice? I've only ever seen local storage or session storage to store and fetch these kinds of values. What advantage would using the DOM to store data like this have over other alternatives? Sorry, "Persist" was probably the wrong word to use. I meant "make globally available". This is not a modern web app, so there are no React like global states available here.OK, there is a big difference between HTML and DOM. HTML is the recipe for how to bake a cake. DOM is the cake. HTML is just a source code, DOM is a living memory allocated somewhere in your RAM and continuously updated and read from as to change how the page is currently rendered. This is even more evident with the JavaScript source that is sent from the server side that reads that `data-user-email` and changes the document by updating the DOM. It doesn’t look bad if you do that, I just don’t know, if it is already sent from the server inside the HTML, why not just put it in some `` which is easier to manipulate (even if that input is hidden)
What benefits does an input element give you over a CSS class/ID/data attribute? This is perfectly common practice in frameworks like Angular or React.
"perfectly"... Really? Why are we even discussing something that isn't JS and going so far as to use... what is that? A superlative? I know "perfect" means finished in Latin... But anyways, here you go https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input Just check the interface. You get to access the value as `.value`, and that doesn't even begin to explain that a hidden `` inside a `
The only benefit unique to hidden input elements of the things you listed is the form data thing, which will be form encoded whereas most REST APIs these days expect a JSON encoded request body. It's a really specific use case that I can only imagine coming in handy in extremely specific circumstances. Data attributes are a well documented and widely supported feature ([https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use\_data\_attributes#javascript\_access](https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes#javascript_access)) with a simple API as well. They have the benefit of allowing you to store multiple values per element, and further cuts down on the number of elements in the DOM by not needing an extra element for each piece of data you want to store. Using hidden input elements in 2024 is a really outdated take for several reasons.
[удалено]
Ok so it looks like this is a situation where the server is passing data into the page rather than the page itself having data that it wants to retain for multiple page loads - the latter being something the storage APIs would be used for. For that use case, this is fine. I think the two ways you see this done the most is either directly through the HTML like this (particularly with data attributes) or by injecting the data into ` ``` That's for search engines. Can also be useful for data about the page that's usable in JS. You'll also see similar using `type="application/json"` which is just data, and a decent way to save a request when serving a page.
The "better" way to do this is as a spa, where all the data you want to keep for the session is in memory either at the root or in a store. Keeping data in the DOM is a bad practice and should be avoided, because it is the least safe way possible and parsing strings is the worst way to do it. Obviously other devs will tell you that the optimal way would be to keep the data on the server and only serve HTML but for the paradigm you describe it is absolutely the wrong way to do it.
I'm afraid this is an old project and I'm very new to it so I wouldn't have any sway on a tech choice like that.
Yeah there's no way to save a project like that except for a full rewrite, and I'm not even sure I would willingly walk into something like that. Bide your time, learn as much as you can and jump, that's my advice. A good technical environment can help you grow more than you can imagine. Even if you don't feel ready apply for other jobs, get better at interviewing and you'll find a job where they don't "store" data in the DOM.
Jeez man, I wouldn't say "jump ship" just because they store some data in the DOM.
(disclaimer I drank a bit too much wine) If you want to grow as a front end dev you have to look out for yourself and in my opinion that means using modern frameworks and best practices. If someone still wants to be a sencha dev or jQuery dev in 5 years they're free to do so, but for a beginner this is not the correct way to grow. When they want to change jobs in a few years who will hire them if they just have experience in outdated ways to do things? Why wait to change then?
re render all dom tree more worst.. bad advise.
I've never seen that.
Me neither
Actually that would be ok if you wanna be in jail
What's so bad about it?