Grump posted:

Yeah I'm only using a bit of Jquery to handle a form submission and pushing the input of a form to an array. And then I'm importing that script to the form component.

My only issue I've been having is that I'm hiding/showing form based on state and I'm having problems getting the script to run correctly after the button to render the form is clicked. I understand that the script isn't running because it can't find #addform on the page because <Form/> hasn't been rendered yet, but I don't get why it won't work after <Form/> has been rendered.

Lumpy posted:

Don't mix jQuery and React unless you really, really, really understand how React handles DOM manipulation. As Helicity said, there's absolutely no reason for you to be using jQuery for this, so don't.

piratepilates posted:

edit: Also since I can be more specific to what you want to do, for your form component all you need to do is have a method on your component for when you want to create the person object (I'm going to assume it's something like "user pressing the enter key"). In that method just create the new person instance as if this was regular plain vanilla JS (because it is!), and push that instance to your array that is holding people (I'm guessing you want to pass the array in to the component as a prop).

Lumpy posted:

To reiterate what piratepilates said in other terms: React *shouldn't* have that stuff in there. React renders what you tell it to, that's it. Obviously a simplification, but yeah, React is the V. Your model can be whatever you want (Redux, Angular, plain old JS you write yourself, an external API / Firebase) and you use actions to let the view inform the model (or controller, or whatever) that something happened in your app. Your code is then responsible for passing new state to your view when something changes outside of it (an API request completed or failed, etc.)

In my React apps, React is about 10-20% of the code. You can build a functional, unit tested Redux app that's "feature complete" before you even npm -i react.

Grump posted:

yeah. I'm definitely aware that I don't really need JQuery. It's bad practice, and I was just being lazy. I'll definitely re-write that part.


Okay. I think there was just a misunderstanding because I was following early advice provided by you and piratepilates.



I guess I'm just confused about how you can push the new Person instance to an array in React, rather than just creating a method inside my Form component and writing it in vanilla Javascript.

But I'm assuming the short answer is just read up on Redux?

Also, thanks for bearing with me, everybody! I realize that I'm being a pain in the rear end. This is just super frustrating for me to learn this library.

Grump posted:

I guess I'm just confused about how you can push the new Person instance to an array in React, rather than just creating a method inside my Form component and writing it in vanilla Javascript.

But I'm assuming the short answer is just read up on Redux?

Also, thanks for bearing with me, everybody! I realize that I'm being a pain in the rear end. This is just super frustrating for me to learn this library.

Helicity posted:

Sounds like you've never experienced the bliss of working in a giant SPA that is jQuery BBQ wrapped by Angular, with a dash of React thrown in (using both Flux and Redux of course).

Grump posted:

But I'm assuming the short answer is just read up on Redux?

Also, thanks for bearing with me, everybody! I realize that I'm being a pain in the rear end. This is just super frustrating for me to learn this library.

geeves posted:

If you had said Angular dumpster fire, then I would wonder if you were one of my coworkers.

Lumpy posted:

As for how to make Persons and put them in an array....

Helicity posted:

Short answer IMO is read up on Event Sourcing for an afternoon, and then Redux.

Pollyanna posted:

I don't know what you guys are talking about, Redux is really easy:

Helicity posted:

We do use that term sometimes, but I don't think we hate the Angular part nearly as much as the rest.

an skeleton posted:

Hi, I was wondering if anyone has a resource, blog, site, etc. that aggregates / talks about / otherwise lists research that is relevant to UX/UI in software engineering / Human-computer Interaction.

edit: anything vaguely similar to this description would also be helpful. im not sure exactly what im looking for other than stuff that could help facilitate data-driven approaches/understanding of UX/UI engineering

Kekekela posted:

Finally got around to using VSCode and am pleasantly amazed. I expected a more Atom-like experience, but VSCode is about a billion times more responsive.

Pollyanna posted:

I don't know what you guys are talking about, Redux is really easy:

Lumpy posted:

Grump posted:

I ended up doing similar in React, without the actual need for Redux. I don't know what this may look like to you guys, but it seems to work. This will effectively make my form data into an object, put that object into an array (which is the state of the app), and print it out as an entry. I may be making my life harder when I go to edit and delete these entries, but I guess we'll see.

When a new contact gets added, the state ends up looking like this

state{
people: [{
fname: jerry
lname: jones
email: asdf@gmail.com
address: 123 Fake St
phone: 1231231234
},
{
fname: ken
lname: lewis
email: aaaaaa@gmail.com
address: 4324 Faker St
phone: 5436541232
}]
}

Redux was just going over my head too much. It's so confusing. I think I have to start with smaller exercises to grasp it better.

So I now have three components: Entries.js (which will list each new person), Form.js (simply holds the form) and Parent.js (which holds the state to be changed and the function that runs when the form is submitted)

Parent.js

code:

class Parent extends Component {
    constructor(props, context) {
        super(props, context);
        //set state to an empty array
        this.state = {
            people: []
        };
    }
    handleSubmit = e => {
        e.preventDefault(); //prevent form from refreshing the page
        var myForm = document.getElementById('addform');
        let data = new FormData(myForm); //grabs all the input data from the form
        var eachPerson = {}; //eachPerson will concatonate with this.state, so it will end up being an array of objects
        for (let [key,
            val]of data.entries()) {
            eachPerson[key] = val;
        } //object will end up looking like this {fname: "Joe"}
        var people = [
            ...this.state.people,
            eachPerson
        ] //add the new object to the people array
        this.setState({people});
        document
            .getElementById("addform")
            .reset(); //reset the input fields onsubmit
    }
    render() {
        return (
            <div>
                //form will run handleSubmit when submitted
                <Form onClick={this.handleSubmit}/>
                //the state of parent is passed to entries as a prop
                <Entries people={this.state.people}/>
            </div>
        )
    }
}

Form.js

code:

class Form extends Component {
    render() {
        return (
            <form id="addform" name="addform" onSubmit={this.props.onClick}>
                <input type="text" name="fname" placeholder="First name" required />
                <input type="text" name="lname" placeholder="Last name" required />
                <input type="email" name="email" placeholder="email" required />
                <input type="input" name="address" placeholder="address" required />
                <input type="tel" name="phone" placeholder="phone number" required />
                <input type="submit" id="submitbtn" value="Submit"/>
                <button type="button" id="closebtn" onClick={this.props.onClick}>
                    Close</button>
            </form>
        );
    }
}

Entries.js

code:

class Entries extends Component {
  render() {
    // Parent'js state (an array named people) was passed to entries as a prop //
    // map over each object in the people array
    let peopleData = this
      .props
      .people
      .map((object, index) => {
        // return each property in each object
        return (
          <div key={index}>
            <h1>{object.fname} {object.lname}</h1>
            <p>{object.address}</p>
            <p>{object.email}</p>
            <p>{object.phone}</p>
          </div>
        )
      });
    //display the results of peopleData
    return (
      <div>{peopleData}</div>
    )
  }
}

Grump posted:

I ended up doing similar in React, without the actual need for Redux. I don't know what this may look like to you guys, but it seems to work. This will effectively make my form data into an object, put that object into an array (which is the state of the app), and print it out as an entry. I may be making my life harder when I go to edit and delete these entries, but I guess we'll see.

When a new contact gets added, the state ends up looking like this

gmq posted:

I'm curious about state management. If you're using something like Vuex or Redux, what should go there?

For example I have an accordion component inside a sidebar that can also be collapsed. I think that the accordion's state should manage its own state since I don't really care if the items inside are open or not BUT the sidebar's state (if it's open or not) should be in the store because it's much more probable I'll use that information somewhere else. Is this more or less correct or am I missing something?

Lumpy posted:

If you only have a render function, you can just use that function as the component. It will be passed in props as an argument. You can still do fancy stuff like mapping and using refs even:

gmq posted:

I'm curious about state management. If you're using something like Vuex or Redux, what should go there?

For example I have an accordion component inside a sidebar that can also be collapsed. I think that the accordion's state should manage its own state since I don't really care if the items inside are open or not BUT the sidebar's state (if it's open or not) should be in the store because it's much more probable I'll use that information somewhere else. Is this more or less correct or am I missing something?

Ochowie posted:

You can't use refs in functional components.

edit: Looks like you can use refs inside functional components but not on functional components. Sorry about that.

Kekekela posted:

I didn't think you could use them inside either, or at least my linter doesn't like it.

ddiddles posted:

I'm writing a React/Redux app that uses a firebase back-end.

I have a CompanyView component that fires off an action with componentWillMount to grab the latest companies node inside firebase, which it then formats the response into an array full of individual company objects and pushes it to my redux store. This all works great, I'm able to render a company list with all the data.

I also have an CompanyAdd view that has a form that lets me input company name and company description. I wrote a bit of logic that runs with onChange to take the value of the company name input field, and reference it against all the company names inside my store state. If the input value matches an already existing company, it'll let the user know that company already exists. This also works fine, but the problem is, a visitor would need to visit the route that mounts CompanyView before going to CompanyAdd, otherwise that initial action inside CompanyView would have never fired off, and the store wouldn't have an array of companies.

My question is, what would be the "proper" way to handle that initial action that grabs the companies data? My initial thoughts were:

1. Have that action fire off on both components using componentWillMount, but that would mean that data is being requested twice if the visitor goes to both components, not so good.
2. Have that action fire off in the root <App /> component that wraps everything inside the app, which would ensure the array of companies is created. My app will have other views that don't care about the list of companies on the store, so this seems like a waste as well.
3. Wrap any views that deal with the company data in a container app, and have that container app fire off the action, so no matter what, any view inside that container will have access to the company list on the store.

I'm leaning towards #3, as it seems like the cleanest option. If this was the case, would it make sense to pass the companies data on the store into the containers children as a prop, or have each child view connect to the redux store using connect()?

Thermopyle posted:

Here's an interesting article from Addy Osmani from Google about the startup penalty of js parsing and compiling on Chrome.

Not a ton of actionable things for front-end devlopers beyond:

• Ship less JS
  
• Do code splitting and lazy-load on your routes
  
• Check your frameworks and libraries for their parse cost. As parse/compile is non-linear with the size of js, you can't just compare the shipped byte size of libraries, you have to benchmark their parse/compile time.
  

He also gives some direction on how to use Chrome devtools to do the actual benchmarking.

Pretty interesting throughout. Kinda cringe-inducing to see this:



and this:

Helicity posted:

Even when I show people flamecharts depicting 1 second parse times for React and the initial model for a Top 1000 traffic website, they don't think it's that big of a deal. Nothing is free, damnit - all those libraries and whatnot have a cost. They'll then argue in a code review about how you should use lodash's find() function instead of the baked in filter() because lodash is so much faster (it's actually slower in that specific case), and the difference still comes out to be something like .000001 seconds for the use case in question. loving maddening.

Plavski posted:

My tech lead gets pissed when I bring him examples of complex js optimizations we could make where the difference is 0.01s over 10,000 iterations. "I'd rather have readable code that's slower than unreadable nonsense no-one else will be able to read after we fire you for writing unreadable code."

Doesn't stop me tho

Helicity posted:

OK, here's a real brain buster. We upgraded to Babel 6 and were looking at spec mode:

http://www.2ality.com/2017/01/babel-esm-spec-mode.html

Long story short, your dynamic imports don't meet the spec from what I can tell. Unfortunately, this is how we stub out functions while testing other modules that use those functions.

How are you supposed to stub a function from module A when testing module B that also imports from module A, while remaining spec compliant?

edit: Also, has anyone played around with testdouble or other sinon alternatives? Unit testing is too much of a chore in JS compared to other languages from my experience.

ddiddles posted:

So I did a bunch of googling around about this issue, and a lot of people said it was a good pattern to group your routes with a container component. I went ahead and did that, but it kind of doesn't feel like a good solution. This is what I came up with so far.

Munkeymon posted:

But that really wouldn't help if you're not running that code 10k times in a page lifetime

Thermopyle posted:

Forgall posted:

Is compilation output cached by browsers?

Lumpy posted:

What I did in my Firebase / React app is throw listeners onto the Firebase paths for all the collections I'd need in the app at launch. When they initialize or whenever there is an update, the store is updated via action. Only happens once, app has all the base data it needs no matter what, and I don't have to do anything else. Is it "wasteful" if I never go to the part of the app that needs X part of the state? Maybe, but the app is performant, so I don't worry about it. Don't prematurely optimize! If loading that data brings the app to a crawl on launch, sure, worry, but do what's easy then profile if things get slow.

Munkeymon posted:

But that really wouldn't help if you're not running that code 10k times in a page lifetime