|
Dancer posted:Hi goons.
|
![]() |
|
![]()
|
# ? May 18, 2024 18:44 |
|
I’m having a senior moment…what’s the best way to retrieve the value of a multi select with nodejs?
|
![]() |
|
Empress Brosephine posted:I’m having a senior moment…what’s the best way to retrieve the value of a multi select with nodejs? isn't just an array of selected values keyed on the input name? And wouldn't it maybe be dependent on the web server you are running (i.e. "Node" doesn't know wtf a multiselect is)?
|
![]() |
|
Yeah sorry wrote that in a rush; I’m using expressjs and was wondering how to access it with a req.body request. You are right though, it is a array!
|
![]() |
|
Empress Brosephine posted:Yeah sorry wrote that in a rush; I’m using expressjs and was wondering how to access it with a req.body request. You are right though, it is a array! You're still leaving out a lot here. Is it a application/x-www-form-urlencoded <form> POST, an SPA app that does JSON posts, what?
|
![]() |
|
Edit: nevermind, I've found an alternative tutorial which walks me through installing Fomantic UI within a React app
|
![]() |
|
What's the difference between {foo: 'bar'} and {'foo': 'bar'}? When I send former over the wire, e.g. via Express.js and then parse it on the other end, it turns out like latter. With latter x.foo doesn't work, tho. If I want former, I need to use a "reviver". However, when I specifically try to assign latter to a variable, it becomes the former anyhow.
|
![]() |
|
Combat Pretzel posted:What's the difference between {foo: 'bar'} and {'foo': 'bar'}? When I send former over the wire, e.g. via Express.js and then parse it on the other end, it turns out like latter. With latter x.foo doesn't work, tho. If I want former, I need to use a "reviver". However, when I specifically try to assign latter to a variable, it becomes the former anyhow. Stab in the dark, but pre:{foo: 'bar'}
|
![]() |
|
Combat Pretzel posted:What's the difference between {foo: 'bar'} and {'foo': 'bar'}? When I send former over the wire, e.g. via Express.js and then parse it on the other end, it turns out like latter. With latter x.foo doesn't work, tho. If I want former, I need to use a "reviver". However, when I specifically try to assign latter to a variable, it becomes the former anyhow. There shouldn't be a difference. What do you mean by "With latter x.foo doesn't work"? code:
|
![]() |
|
Combat Pretzel posted:What's the difference between {foo: 'bar'} and {'foo': 'bar'}? When I send former over the wire, e.g. via Express.js and then parse it on the other end, it turns out like latter. With latter x.foo doesn't work, tho. If I want former, I need to use a "reviver". However, when I specifically try to assign latter to a variable, it becomes the former anyhow. In JavaScript source code, JavaScript code:
JavaScript code:
As for "sending over the wire", that's not JavaScript code anymore. You're probably sending JSON, which is not the same thing at all as JavaScript code. Probably what's happening is that somewhere in your client the JavaScript value is getting stringified out as a JSON string: JavaScript code:
|
![]() |
|
Combat Pretzel posted:What's the difference between {foo: 'bar'} and {'foo': 'bar'}? When I send former over the wire, e.g. via Express.js and then parse it on the other end, it turns out like latter. With latter x.foo doesn't work, tho. If I want former, I need to use a "reviver". However, when I specifically try to assign latter to a variable, it becomes the former anyhow. It sounds like you don't understand JSON. You're not sending JS objects directly in requests/responses, you're sending a stringified representation with certain formatting requirements that has to be parsed (some frameworks will do this implicitly for convenience reasons) to get the object back. Combat Pretzel posted:With latter x.foo doesn't work, tho. You're probably trying to do something to a JSON string representation '{"foo": "bar"}', not an object {foo: "bar"}. You need to JSON.parse it to get the object. Combat Pretzel posted:However, when I specifically try to assign latter to a variable JavaScript code:
Roadie fucked around with this message at 20:05 on Mar 25, 2021 |
![]() |
|
One other difference between {foo: 'bar'} and {'foo': 'bar'} is that some Javascript compiler/minifier/obfuscator tools will mangle the former but will not mangle the latter, with the assumption that e.g. replacing 'foo' with 'q' throughout the code will work fine if you've 100% used it object-style, but when you've declared it as explicitly string-keys the compiler will treat it as intentionally string-keys with the assumption that you intended to be able to serialize it or use it to look up things from other containers or the like.
|
![]() |
|
The former is valid JavaScript-only and latter is valid MrMoo fucked around with this message at 17:04 on Mar 26, 2021 |
![]() |
|
The 14-character string "{'foo': 'bar'}" is not valid JSON. JSON requires double quotes around both the key and the value: '{"foo": "bar"}'. But having said that: nobody should be hand-writing JSON messages. I suggest using JSON.stringify({foo: 'bar'}) and letting the serializer handle that.
|
![]() |
|
Doom Mathematic posted:I suggest using JSON.stringify({foo: 'bar'}) and letting the serializer handle that. The correct answer, as you can also play like this: JavaScript code:
|
![]() |
|
e; nevermind I figured it out
Empress Brosephine fucked around with this message at 16:30 on Mar 30, 2021 |
![]() |
|
It seems like if a React application is even a tiny bit complex, the parent components are going to need to know what's going on in the child components. React doesn't support accessing anything in child components (without refs, which seems hacky), and the recommended solution, "lifting up state," is bizarre. Pushing up everything to the top level removes a lot of the benefits of using a framework like React in the first place. Oh yeah, and React doesn't support a nested state, so you're forced to flatten your data and at that point you might as well be using a relational database backed framework like django. Am I looking at this all wrong? TengenNewsEditor fucked around with this message at 14:30 on Apr 5, 2021 |
![]() |
|
TengenNewsEditor posted:It seems like if a React application is even a tiny bit complex, the parent components are going to need to know what's going on in the child components. React doesn't support accessing anything in child components (without refs, which seems hacky), and the recommended solution, "lifting up state," is bizarre. Pushing up everything to the top level removes a lot of the benefits of using a framework like React in the first place. Oh yeah, and React doesn't support a nested state, so you're forced to flatten your data and at that point you might as well be using a relational database backed framework like django. What's wrong with using a callback for child to parent communication?
|
![]() |
|
TengenNewsEditor posted:Am I looking at this all wrong?
|
![]() |
|
Bruegels Fuckbooks posted:What's wrong with using a callback for child to parent communication? That works great if you only need to process the child's state when it changes, but you would still need to cache the result of the callback in the parent if you need to do processing based on the child state later.
|
![]() |
|
Pass an object reference of the child (this) up to the parent somehow, then go hogwild.
|
![]() |
|
Combat Pretzel posted:Pass an object reference of the child (this) up to the parent somehow, then go hogwild. I sure hope this is a joke...
|
![]() |
|
TengenNewsEditor posted:Am I looking at this all wrong? Yeah I think so. Django and React aren't really that comparable of frameworks/libraries and they set out to solve different problems. My sense is that if you'd prefer to work on the view layer in Python, you're probably not the type of developer that React would appeal to. The issue with props drilling/lifting up state is a commonly identified pain point. If a React app has some appreciable level of complexity, developers usually install a state management library like Redux or zustand.
|
![]() |
|
Yeah, this isn’t exactly a hot take, redux has been around for five years. It even got to the point where everyone was using redux everywhere and it was taught in beginner tutorials so the redux site now has a page on why you should not use it. I think React context is a decent alternative now?
|
![]() |
|
Combat Pretzel posted:Pass an object reference of the child (this) up to the parent somehow, then go hogwild. xtal posted:I sure hope this is a joke... Honestly this is the most attractive suggestion I've seen so far (aside from 'don't use react) - and that fact that it is not "react-like" sours me on react even more. fsif posted:Yeah I think so. Django and React aren't really that comparable of frameworks/libraries and they set out to solve different problems. My sense is that if you'd prefer to work on the view layer in Python, you're probably not the type of developer that React would appeal to. I don't want to use django since this app shouldn't require an ORM. My point is if I need to use a state manager or normalize/flatten my state application wide, am I even getting any benefit from using React over a heavy ORM framework anymore?
|
![]() |
|
TengenNewsEditor posted:It seems like if a React application is even a tiny bit complex, the parent components are going to need to know what's going on in the child components. React doesn't support accessing anything in child components (without refs, which seems hacky), and the recommended solution, "lifting up state," is bizarre. Pushing up everything to the top level removes a lot of the benefits of using a framework like React in the first place. Oh yeah, and React doesn't support a nested state, so you're forced to flatten your data and at that point you might as well be using a relational database backed framework like django. I'm about to experiment with Recoil, as it seems to solve the shortcomings of Redux state management for any moderate+ complexity.
|
![]() |
|
smackfu posted:Yeah, this isn’t exactly a hot take, redux has been around for five years. Context can't be dynamic, thus my above take. The recoil.js intro video explains a bunch of benefits of its approach, and seems to solve dynamic shared state pretty elegantly.
|
![]() |
|
TengenNewsEditor posted:I don't want to use django since this app shouldn't require an ORM. My point is if I need to use a state manager or normalize/flatten my state application wide, am I even getting any benefit from using React over a heavy ORM framework anymore? I assume so? You're getting all of the normal benefits of React and something like zustand or the aforementioned native Context API take about thirty minutes to learn and are much lighter weight than an ORM framework. They will give you a global state object, which is what I think you're looking for.
|
![]() |
|
A global state manager shouldn't be necessary to get properties from a child component. It's insane that composition is fundamentally broken and the answer is 'use a global state manager'. (Recoil does look like a pretty good state manager though)
|
![]() |
|
TengenNewsEditor posted:It seems like if a React application is even a tiny bit complex, the parent components are going to need to know what's going on in the child components. React doesn't support accessing anything in child components (without refs, which seems hacky), and the recommended solution, "lifting up state," is bizarre. Pushing up everything to the top level removes a lot of the benefits of using a framework like React in the first place. Oh yeah, and React doesn't support a nested state, so you're forced to flatten your data and at that point you might as well be using a relational database backed framework like django. You are probably looking at it all wrong. I have written many complex React apps, and "parent components needing to know what is going on in the child components" is not a thing that comes up much, if ever. Can you give an example of the issues you are facing?
|
![]() |
|
React is entirely built around the idea of unidirectional top-down data flow. Accessing a child component's properties is a big anti-pattern and red flag. If you find yourself wanting to communicate back up the component tree, in most cases, pulling state up is the most appropriate solution. For the rare instances when you really need to communicate child state updates back up the tree, escape hatches exist: passing callback functions as props, using context, or bringing in a state management library like redux (yuck, don't do this). I'm getting big XY problem vibes here though.
Ima Computer fucked around with this message at 17:29 on Apr 5, 2021 |
![]() |
|
fireraiser posted:React is entirely built around the idea of unidirectional top-down data flow. Accessing a child component's properties is a big anti-pattern and red flag. If you find yourself wanting to communicate back up the component tree, in most cases, pulling state up is the most appropriate solution. For the rare instances when you really need to communicate child state updates back up the tree, escape hatches exist: passing callback functions as props, using context, or bringing in a state management library like redux (yuck, don't do this). I'm getting big XY problem vibes here though. Same. What are you actually trying to do here, TengenNewsEditor?
|
![]() |
|
Let me ask this - where is business logic supposed to go in a client-side only react app? Assuming you're avoiding a state management library. Putting it child components requires communicating the results up the tree. For example if an account profile totals itself, the parent customer profile will need to get the totals from all the accounts to create an overall total. If you put it all in a top level component you end up with a god component. React seems like it ought to work best as a View only framework - that suggests the business logic ought to be elsewhere, let's say in vanilla javascript, and then sending the data top-down through all the components. That seems fine, but there isn't much documentation or conversation on this workflow and it seems pretty difficult to send changes to react from 'outside'. TengenNewsEditor fucked around with this message at 18:09 on Apr 5, 2021 |
![]() |
|
Roadie posted:Same. What are you actually trying to do here, TengenNewsEditor? Honestly I just want to understand how unidirectional top-down flow is intended to work for an application with client-side business logic. Nearly all the examples I've seen sidestep the issue by using a global state manager.
|
![]() |
|
TengenNewsEditor posted:React seems like it ought to work best as a View only framework That's—out of the box—all React has purported to be. It's narrow in scope and extendable by design. If you don't like cobbling together third party libraries for things like state management, routing, or server side rendering, you can either choose a more fleshed out React starter pack like Next.js, or choose a different, more opinionated JavaScript framework like Vue.
|
![]() |
|
TengenNewsEditor posted:For example if an account profile totals itself, the parent customer profile will need to get the totals from all the accounts to create an overall total. This is a fundamentally bad thing to do in React because you're going to be re-rendering everything a whole bunch of times as all your updaters fire off. Do it declaratively, not imperatively: define your totals as a derived value of your incoming data, with memoized wrappers if necessary to reduce total recalculation. TengenNewsEditor posted:Honestly I just want to understand how unidirectional top-down flow is intended to work for an application with client-side business logic. Nearly all the examples I've seen sidestep the issue by using a global state manager. TengenNewsEditor posted:React seems like it ought to work best as a View only framework - that suggests the business logic ought to be elsewhere, let's say in vanilla javascript, and then sending the data top-down through all the components. That seems fine, but there isn't much documentation or conversation on this workflow and it seems pretty difficult to send changes to react from 'outside'. For this kind of setup, the global state manager is where you put your client-side business logic. The reason Redux is so popular for this is that it plays nice with React's top-down-data-flow concept while allowing arbitrarily complex custom extensions once you add in middleware.
|
![]() |
|
Thanks, if you look at react as a 'view-only' framework, top-down unidirectional makes a lot more sense. But if it's a view-only library why is it such a pain in the rear end to get external data into it? And if you're supposed to populate the top level component with a model of your entire application, how do you manage page re-renders for a nested state? Do you need a global state manager if you're not able to flatten out your application's model?
|
![]() |
|
TengenNewsEditor posted:Thanks, if you look at react as a 'view-only' framework, top-down unidirectional makes a lot more sense. TengenNewsEditor posted:And if you're supposed to populate the top level component with a model of your entire application, how do you manage page re-renders for a nested state? Do you need a global state manager if you're not able to flatten out your application's model?
|
![]() |
|
Roadie posted:It's not, though? Actually really helpful. One of the tests I had tried was a vanilla JS app that sent output to a top level react Component. It hadn't worked before but your comment spurred me to go back to it and find the problem. The other part was asking how to deal with react only updating when the top level state object changes, and failing to update if a member of the state object changes. But that's an understandable limitation & I know some of the common workarounds.
|
![]() |
|
![]()
|
# ? May 18, 2024 18:44 |
|
TengenNewsEditor posted:The other part was asking how to deal with react only updating when the top level state object changes, and failing to update if a member of the state object changes. But that's an understandable limitation & I know some of the common workarounds. React uses shallow equality for props/state update comparisons. If you want it to re-render, give it a new object (and new objects for any updated properties), not a mutated object. This is part of why so many examples out there default to spread syntax for setState or reducer syntax. Roadie fucked around with this message at 23:41 on Apr 5, 2021 |
![]() |