Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »

huhu: Feb 24, 2006

dupersaurus posted:

Markdown?

This gave me an interesting idea and I think serves for my needs without using another library to parse. Thought I'd share.

A post's content could look like:

code:

h1#Hello World
p#This is some body text.
img#[url]http://localhost:8000/foo.jpg[/url]

And on the front end I added:

code:

    parseContent = rawContent => {
        const lines = rawContent.match(/[^\r\n]+/g)

        return lines.map(line => {
            const [tag, content] = line.split(/#(.+)/)

            switch (tag) {
                case 'h1':
                    return <Header size="large">{content}</Header>
                    break
                case 'p':
                    return <Text>{content}</Text>
                    break
                case 'img':
                    return <img src={content} />
                default:
                    return <Text>{content}</Text>
            }
        })
    }

# ? Sep 22, 2018 16:48

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 04:20

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

huhu posted:

This gave me an interesting idea and I think serves for my needs without using another library to parse. Thought I'd share.

A post's content could look like:

code:

h1#Hello World
p#This is some body text.
img#[url]http://localhost:8000/foo.jpg[/url]

And on the front end I added:

code:

    parseContent = rawContent => {
        const lines = rawContent.match(/[^\r\n]+/g)

        return lines.map(line => {
            const [tag, content] = line.split(/#(.+)/)

            switch (tag) {
                case 'h1':
                    return <Header size="large">{content}</Header>
                    break
                case 'p':
                    return <Text>{content}</Text>
                    break
                case 'img':
                    return <img src={content} />
                default:
                    return <Text>{content}</Text>
            }
        })
    }

The only issue with this is that you may eventually be asked to add support for lists, multiple headline styles, etc. And then you've just reinvented Markdown with a less well tested parser.

# ? Sep 22, 2018 17:58

huhu: Feb 24, 2006

Lumpy posted:

The only issue with this is that you may eventually be asked to add support for lists, multiple headline styles, etc. And then you've just reinvented Markdown with a less well tested parser.

It's my project so I don't aim to ask that of myself. All I wanted was headers, text, and images.

# ? Sep 22, 2018 18:11

geeves: Sep 16, 2004

Lumpy posted:

The only issue with this is that you may eventually be asked to add support for lists, multiple headline styles, etc. And then you've just reinvented Markdown with a less well tested parser.

The 2nd problem is regex.

Esp this line: const [tag, content] = line.split(/#(.+)/)

What happens with #hashtags in your content? Or a URL that has a # in it because reasons?

code:

p#T#his is some body text. #goonsex and this is a great tweet for #cobol

You potentially just lost your content. That logic w/switch might need some firstIndexOf work.

# ? Sep 22, 2018 20:59

huhu: Feb 24, 2006

geeves posted:

The 2nd problem is regex.

Esp this line: const [tag, content] = line.split(/#(.+)/)

What happens with #hashtags in your content? Or a URL that has a # in it because reasons?
code:
p#T#his is some body text. #goonsex and this is a great tweet for #cobol
You potentially just lost your content. That logic w/switch might need some firstIndexOf work.

Thanks for catching this!

Another question. I've got an App.js structured like this:

code:

                <AppWrapper>
                        <Navigation someThing={someThing} />
                        <Switch>
                            <Route exact path="/" component={Home} />
                            <Route exact path="/page" component={Page} />
                        </Switch>
                </AppWrapper>

I want to do someThing conditionally depending on the route. I couldn't figure out a good solution, or maybe I did. I ended up wrapping index.js which serves App.js like so:

code:

ReactDOM.render(
    <BrowserRouter>
        <Switch>
            <Route path="/" component={App} />
        </Switch>
    </BrowserRouter>,
    document.getElementById('root')
)

So then I could add logic like so in App.js:

code:

    componentWillMount() {
        const {
            location: { pathname }
        } = this.props

        this.setState({ pathname, someThing: pathname !== '/' })
}

Is there a better way to do this I'm missing?

# ? Sep 23, 2018 15:49

dupersaurus: Aug 1, 2012; Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

huhu posted:

Thanks for catching this!

Another question. I've got an App.js structured like this:
code:
                <AppWrapper>
                        <Navigation someThing={someThing} />
                        <Switch>
                            <Route exact path="/" component={Home} />
                            <Route exact path="/page" component={Page} />
                        </Switch>
                </AppWrapper>
I want to do someThing conditionally depending on the route. I couldn't figure out a good solution, or maybe I did. I ended up wrapping index.js which serves App.js like so:
code:
ReactDOM.render(
    <BrowserRouter>
        <Switch>
            <Route path="/" component={App} />
        </Switch>
    </BrowserRouter>,
    document.getElementById('root')
)
So then I could add logic like so in App.js:
code:
    componentWillMount() {
        const {
            location: { pathname }
        } = this.props

        this.setState({ pathname, someThing: pathname !== '/' })
}
Is there a better way to do this I'm missing?

Go check out the react router docs, I don�t remember what it is but I�m pretty sure they have something for exactly that.

# ? Sep 23, 2018 16:26

Dominoes: Sep 20, 2007

Is there a way to leave a javascript file out of Webpack 4's bundler, for use as a separate, editable config? Ie I have a .ts file (Could as easily be JS) that contains simple arrays of values, similar to JSON). I'd like to be able to edit that file separately from the bundle, and have the changes take effect immediately without transpiling. I suspect the solution involves a tweak to webpack.config.js .

# ? Sep 24, 2018 22:00

huhu: Feb 24, 2006

Dominoes posted:

Is there a way to leave a javascript file out of Webpack 4's bundler, for use as a separate, editable config? Ie I have a .ts file (Could as easily be JS) that contains simple arrays of values, similar to JSON). I'd like to be able to edit that file separately from the bundle, and have the changes take effect immediately without transpiling. I suspect the solution involves a tweak to webpack.config.js .

Perhaps this?
https://stackoverflow.com/questions/44376589/webpack-exclude-a-specific-file

# ? Sep 25, 2018 03:48

ArcticZombie: Sep 15, 2010

I'm learning React and I'm creating an absolute horror on my own here.

I'm trying to implement toggleable options, or settings. These options can be grouped in a option category, e.g.:

pre:

Frobnication
    foo
    bar
    baz

The entire category might also be toggleable, toggling it will enable/disable all the suboptions.

So I have an OptionCategory component as well as an Option component. Looking at the React tutorial, I should "lift state up" (https://reactjs.org/docs/lifting-state-up.html) here so that the OptionCategory holds the state for all the suboptions. Where my needs differ from what's shown in the example in the tutorial however, is that I don't necessarily know what options are going to be in the category ahead of time. If I use composition and use this.props.children in the render function of the category, I can't then control the props of the children from within the category to enable/disable the options (they are immutable).

Additionally, if a category is enabled, but all the suboptions are disabled by the user, the category should become disabled too. Likewise, if a category is disabled but a user enables a suboption, it should become enabled. How can the children components cause a change in state of the parent category? They aren't even aware the parent exists.

e: post is not preview

ArcticZombie fucked around with this message at 21:38 on Sep 26, 2018

# ? Sep 26, 2018 21:29

Ahz: Jun 17, 2001; PUT MY CART BACK? I'M BETTER THAN THAT AND YOU! WHERE IS MY BUTLER?!

ArcticZombie posted:

I'm learning React and I'm creating an absolute horror on my own here.

I'm trying to implement toggleable options, or settings. These options can be grouped in a option category, e.g.:
pre:
Frobnication
    foo
    bar
    baz
The entire category might also be toggleable, toggling it will enable/disable all the suboptions.

So I have an OptionCategory component as well as an Option component. Looking at the React tutorial, I should "lift state up" (https://reactjs.org/docs/lifting-state-up.html) here so that the OptionCategory holds the state for all the suboptions. Where my needs differ from what's shown in the example in the tutorial however, is that I don't necessarily know what options are going to be in the category ahead of time. If I use composition and use this.props.children in the render function of the category, I can't then control the props of the children from within the category to enable/disable the options (they are immutable).

Additionally, if a category is enabled, but all the suboptions are disabled by the user, the category should become disabled too. Likewise, if a category is disabled but a user enables a suboption, it should become enabled. How can the children components cause a change in state of the parent category? They aren't even aware the parent exists.

e: post is not preview

Have your parent pass closure functions to change the parent state to the children as props.

# ? Sep 26, 2018 21:45

ArcticZombie: Sep 15, 2010

Ahz posted:

Have your parent pass closure functions to change the parent state to the children as props.

But if I'm using composition:

code:

<OptionCategory label="Frobnication">
    <Option label="foo"/>
    <Option label="bar"/>
    <Option label="baz"/>
</OptionCategory>

It's too late for the OptionCategory to give props to the children, no? They are immutable.

# ? Sep 26, 2018 21:57

Analytic Engine: May 18, 2009; not the analytical engine

Has anyone successfully mixed Python HTML templates (jinja2/etc) with React? I'm making login and registration pages for my React SPA and it would really help to leverage flask_wtf forms. Currently I have a janky setup where Flask templates set window variables in index.html before I call the React <script>s which use dangerouslySetInnerHTML, and that's clearly stupid.

Broadly, this is about how you mix server-side HTML templating with React JS code. If it's better to learn server-side React stuff then I could do that.

# ? Sep 27, 2018 00:22

Dominoes: Sep 20, 2007

ArcticZombie: Group all settings in a single object, to make passing to subcomponents cleaner.

JavaScript code:

interface Options {
    settingA1: boolean
    settingA2: boolean
    groupA: boolean
    settingB1: boolean
    setting B2: boolean
    groupB: boolean
}

interface MainState {
    options: Options
    // Other things

}

Create a method in your top-level component to set the options, and pass both this method, and the options to your form. Pass the options to whatever consumes the form, and use individual setting items, or group items as appropriate. In your form, make the widgets associated with each option show selected when either the option, or the group is True.

JavaScript code:

// Inside your top-level component, which is class-based, and has a state of type MainState
setOption(option: string, val: boolean) {
    this.setState({options: {...this.state.options, [option]: val})
}

// ...

render() {
    <Form options={this.state.options} optionCb={this.setOption} />
}

Example section of the form:

JavaScript code:

const Form = ({options, optionCb}: {options: Options, optionCb: Function}) => (
    <Check selected={options.settingA1 || options.groupA} onClick={() => 
          optionCb('settingA1', !options.settingA1)} name="A1" />
	// (Note that the cb value logic in this example is oversimplified; it doesn't 
        // handle quirks involving the group vs individual logic.
)

If you'd like details on the parts I didn't explicitly write as code examples (Like the group vs individual option logic, or how to initialize state and methods in a class-based React component), ask.

Dominoes fucked around with this message at 02:32 on Sep 27, 2018

# ? Sep 27, 2018 00:34

Dominoes: Sep 20, 2007

Do y'all know if it's possible to run frontend apps that use WASM from local HTML files, ie without a server? It's working in Edge for me, but in FF I get the error: "TypeError: Response has unsupported MIME type", and in Chrome: "Fetch API cannot load file:///C:/...module.wasm. URL scheme must be "http" or "https" for CORS request."

I suspect this isn't supported in most browsers; my use-case is running an app at work, where I can't install a server. Was hoping to move parts of the code to Rust. The page loads, but the WASM-content doesn't. (Except in Edge)

Dominoes fucked around with this message at 05:52 on Sep 27, 2018

# ? Sep 27, 2018 05:50

M31: Jun 12, 2012

ArcticZombie posted:

But if I'm using composition:
code:
<OptionCategory label="Frobnication">
    <Option label="foo"/>
    <Option label="bar"/>
    <Option label="baz"/>
</OptionCategory>
It's too late for the OptionCategory to give props to the children, no? They are immutable.

Hoist the state further:

code:

<OptionCategory label="Frobnication" checked={[this.state.foo, this.state.bar, this.state.baz]} onChange={checked -> this.setState({foo: checked, bar: checked, baz: checked})>
    <Option label="foo" checked={this.state.foo} onChange={foo -> this.setState({foo})/>
    <Option label="bar" checked={this.state.bar} onChange={bar -> this.setState({bar})/>
    <Option label="baz" checked={this.state.baz} onChange={baz -> this.setState({baz})/>
</OptionCategory>

There are other solutions, but this is the most straight forward one

# ? Sep 27, 2018 07:41

spacebard: Jan 1, 2007; Football~

Dominoes posted:

Do y'all know if it's possible to run frontend apps that use WASM from local HTML files, ie without a server? It's working in Edge for me, but in FF I get the error: "TypeError: Response has unsupported MIME type", and in Chrome: "Fetch API cannot load file:///C:/...module.wasm. URL scheme must be "http" or "https" for CORS request."

I suspect this isn't supported in most browsers; my use-case is running an app at work, where I can't install a server. Was hoping to move parts of the code to Rust. The page loads, but the WASM-content doesn't. (Except in Edge)

I think this might work as a browser extension rather than a local URL even though it's not HTTP or HTTPS. I did something similar (not WebAssembly) a few years ago and it worked in Chrome, but not Firefox (or Safari) at the time. However that was before Firefox adopted web extensions fully so cross-origin support in extensions could be supported better now.

# ? Sep 27, 2018 13:26

Dominoes: Sep 20, 2007

spacebard posted:

I think this might work as a browser extension rather than a local URL even though it's not HTTP or HTTPS. I did something similar (not WebAssembly) a few years ago and it worked in Chrome, but not Firefox (or Safari) at the time. However that was before Firefox adopted web extensions fully so cross-origin support in extensions could be supported better now.

Thanks. I think the best solution is to just not use WASM in this case. Current best-practices for webapps seems to be always use a server; eg a dev server if running locally; opening local HTML files seems to be on its way out, but is suited to my use case for this project.

# ? Sep 27, 2018 15:30

my bony fealty: Oct 1, 2008

I'm giving my first lightning talk at my JS meetup next Tuesday and I am nervous and excited! The imposter syndrome never goes away does it. Its about trying out GraphQL with existing REST APIs so I hope folks like that.

Do y'all have JS or webdev meetup groups that are good? I find ours very valuable and enjoyable.

# ? Sep 27, 2018 22:26

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

I know if I was allowed to talk for a period of time I'd start talking about RxJS and wouldn't shut up.

# ? Sep 27, 2018 23:05

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

I'll never understand how people get so passionate about RxJS. The documentation is such poo poo and it's near impossible to learn when you first start using it

# ? Sep 28, 2018 00:25

LOOK I AM A TURTLE: May 22, 2003; "I'm actually a tortoise."; Grimey Drawer

Grump posted:

I'll never understand how people get so passionate about RxJS. The documentation is such poo poo and it's near impossible to learn when you first start using it

People get excited about the FRP paradigm that RxJS implements. It lets you implement complex UI logic with small, elegant functions.

I agree the documentation could be better. Sometimes the main description of an operator appears to a novice as essentially word salad, like "Frob takes two observables and emits a single observable that emits a new observable for every observable that the original two observables emit." Many a time I've read the description of some operator and felt like I've come away with less information than I had when all I knew was the name. For me looking at the marble diagrams is usually the best way to get a feel for what an operator does. http://rxmarbles.com/ is a great resource for that.

However, I think the part about it being hard to learn is sort of unavoidable. It's a pretty different way of thinking about programming, and most people have little previous experience with it. You should think of it as akin to learning OOP, or like learning functional programming in general. Learning that poo poo takes years, but it's worth it.

# ? Sep 28, 2018 09:54

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

LOOK I AM A TURTLE posted:

People get excited about the FRP paradigm that RxJS implements. It lets you implement complex UI logic with small, elegant functions.

I agree the documentation could be better. Sometimes the main description of an operator appears to a novice as essentially word salad, like "Frob takes two observables and emits a single observable that emits a new observable for every observable that the original two observables emit." Many a time I've read the description of some operator and felt like I've come away with less information than I had when all I knew was the name. For me looking at the marble diagrams is usually the best way to get a feel for what an operator does. http://rxmarbles.com/ is a great resource for that.

However, I think the part about it being hard to learn is sort of unavoidable. It's a pretty different way of thinking about programming, and most people have little previous experience with it. You should think of it as akin to learning OOP, or like learning functional programming in general. Learning that poo poo takes years, but it's worth it.

That's why I learned Elm. Good docs and like you said, that "other way of thinking" is really worth exploring.

# ? Sep 28, 2018 14:01

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

I have a long list of complicated objects that I'm trying to render in groups with sub-groups (and also multiple, different sbu-sub-groups on the same line) in React. To make whole sub-groups selectable, my vurry clevar idea was to do

code:

<input type="checkbox"
    value={group.map(m => m.Id)}
    checked={this.props.selectedItems[group[0].Id]}
    onChange{this.addOrRemoveSelectedIds} />

Where selectedItems is an object acting as a poor man's map where the reducer sets the selectedItems[id] = true when they're added and delete selectedItems[id] when they're deselected. One problem is that, when I leave the jsx like the above, React will complain about rendering uncontrolled inputs, if it has to render one that's checked, but not when it's actually checked, just when the groups are re-rendered.

I tried to solve that problem by changing the checked condition to {!!this.props.selectedItems[group[0].Id]} so it's always true or false instead of true or undefined. That prevents the inputs from rendering as checked when clicked, even though the reducer runs as expected and the mapping is set. I put a breakpoint on the line that renders the table row and it never runs and something (presumably React's event handler wrapper clears the check when I click on it.

How do I make this work?

e: calling this.forceUpdate() in the handler is a bandaid, but this thing takes two seconds to render, so I really need to slice this up into components

Munkeymon fucked around with this message at 19:10 on Sep 28, 2018

# ? Sep 28, 2018 18:00

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

Grump posted:

I'll never understand how people get so passionate about RxJS. The documentation is such poo poo and it's near impossible to learn when you first start using it

I'm not going to lie and tell you the Observable model wasn't just the most mysterious poo poo I've ever seen when I saw it and I still need to cross-reference my other examples of it when I go to write it but it's baller and I love it.

# ? Sep 28, 2018 21:33

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Munkeymon posted:

I have a long list of complicated objects that I'm trying to render in groups with sub-groups (and also multiple, different sbu-sub-groups on the same line) in React. To make whole sub-groups selectable, my vurry clevar idea was to do
code:
<input type="checkbox"
    value={group.map(m => m.Id)}
    checked={this.props.selectedItems[group[0].Id]}
    onChange{this.addOrRemoveSelectedIds} />
Where selectedItems is an object acting as a poor man's map where the reducer sets the selectedItems[id] = true when they're added and delete selectedItems[id] when they're deselected. One problem is that, when I leave the jsx like the above, React will complain about rendering uncontrolled inputs, if it has to render one that's checked, but not when it's actually checked, just when the groups are re-rendered.

I tried to solve that problem by changing the checked condition to {!!this.props.selectedItems[group[0].Id]} so it's always true or false instead of true or undefined. That prevents the inputs from rendering as checked when clicked, even though the reducer runs as expected and the mapping is set. I put a breakpoint on the line that renders the table row and it never runs and something (presumably React's event handler wrapper clears the check when I click on it.

How do I make this work?

e: calling this.forceUpdate() in the handler is a bandaid, but this thing takes two seconds to render, so I really need to slice this up into components

Ouch. My guess is "group" is the stickler, but seeing a lone snippet of JSX makes it hard to figure out what the problem could be.

# ? Sep 28, 2018 22:05

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Lumpy posted:

Ouch. My guess is "group" is the stickler, but seeing a lone snippet of JSX makes it hard to figure out what the problem could be.

What other context do you need? Reducers look like

JavaScript code:

//select
const selectedItems = state.selectedItems;
for (var i = 0; i < action.payload.length; ++i) {
  selectedItems[action.payload[i]] = true;
}
return {
  ...state,
  selectedItems: selectedItems,
}

//deselect
const selectedItems = state.selectedItems;
for (var i = 0; i < action.payload.length; ++i) {
  delete selectedItems[action.payload[i]];
}
return {
  ...state,
  selectedItems: selectedItems,
}

Pretty basic set implemented with object properties, because IDK what Babel is going to emit if I try to use a Set and I don't want to be second-guessing it. I'm also paranoid about memory use because the state it's working on is pretty big. This tab is using about as much memory as the Gmail tab and this is just an MVP.

# ? Oct 1, 2018 15:09

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Munkeymon posted:

What other context do you need? Reducers look like
JavaScript code:
//select
const selectedItems = state.selectedItems;
for (var i = 0; i < action.payload.length; ++i) {
  selectedItems[action.payload[i]] = true;
}
return {
  ...state,
  selectedItems: selectedItems,
}

//deselect
const selectedItems = state.selectedItems;
for (var i = 0; i < action.payload.length; ++i) {
  delete selectedItems[action.payload[i]];
}
return {
  ...state,
  selectedItems: selectedItems,
}
Pretty basic set implemented with object properties, because IDK what Babel is going to emit if I try to use a Set and I don't want to be second-guessing it. I'm also paranoid about memory use because the state it's working on is pretty big. This tab is using about as much memory as the Gmail tab and this is just an MVP.

Just to double check:

- You've looked at the Redux dev tools and seen the action w/ the correct payload and noticed the state diff?

Also, I suspect this:

JavaScript code:

const selectedItems = state.selectedItems;
for (var i = 0; i < action.payload.length; ++i) {
  delete selectedItems[action.payload[i]];
}

is modifying the state directly (IIRC you are deleting stuff in a reference to state.selectedItems, so are deleting from the state object) and so when the reducer returns, it's comparing the new state.selectedItems with the state.selectedItems you deleted from and sees no difference. You could try setting those items to false like this to test it:

JavaScript code:

const updatedItems = {}
for (var i = 0; i < action.payload.length; ++i) {
  updatedItems[action.payload[i]] = false; 
}
return {
  ...state,
  selectedItems: Object.assign({}, state.selectedItems, updatedItems),
}

Which does not modify the initial state.selectedItems like your examples do.

EDIT: Or alternately create a copy of selected items in your functions like so:

JavaScript code:

//select
const selectedItems = Object.assign({}, state.selectedItems);
// now local selectedItems is *not* a reference
for (var i = 0; i < action.payload.length; ++i) {
  selectedItems[action.payload[i]] = true;
}
return {
  ...state,
  selectedItems: selectedItems,
}

Lumpy fucked around with this message at 14:05 on Oct 3, 2018

# ? Oct 3, 2018 14:02

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Lumpy posted:

Just to double check:

- You've looked at the Redux dev tools and seen the action w/ the correct payload and noticed the state diff?

Also, I suspect this:
JavaScript code:
const selectedItems = state.selectedItems;
for (var i = 0; i < action.payload.length; ++i) {
  delete selectedItems[action.payload[i]];
}
is modifying the state directly (IIRC you are deleting stuff in a reference to state.selectedItems, so are deleting from the state object) and so when the reducer returns, it's comparing the new state.selectedItems with the state.selectedItems you deleted from and sees no difference. You could try setting those items to false like this to test it:
JavaScript code:
const updatedItems = {}
for (var i = 0; i < action.payload.length; ++i) {
  updatedItems[action.payload[i]] = false; 
}
return {
  ...state,
  selectedItems: Object.assign({}, state.selectedItems, updatedItems),
}
Which does not modify the initial state.selectedItems like your examples do.

EDIT: Or alternately create a copy of selected items in your functions like so:
JavaScript code:
//select
const selectedItems = Object.assign({}, state.selectedItems);
// now local selectedItems is *not* a reference
for (var i = 0; i < action.payload.length; ++i) {
  selectedItems[action.payload[i]] = true;
}
return {
  ...state,
  selectedItems: selectedItems,
}

The Redux dev tools exhaust memory and I have to close the inspector and reload the page if I try to use them, so I've been debugging with breakpoints like a caveman, but you're correct and changing the assignment to const selectedItems = { ...state.selectedItems }; corrected it, so I can probably change my deselect reducer to just not copy across the deselected properties.

Munkeymon fucked around with this message at 14:24 on Oct 3, 2018

# ? Oct 3, 2018 14:16

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

If I know a DOM subtree can be affected by this global state, but often won't be and I know when it will and won't be, that's a good time to split that subtree out into a (not sure of the right jargon for the following) high-level component with its own reducers and whatnot, right?

# ? Oct 3, 2018 16:29

LOOK I AM A TURTLE: May 22, 2003; "I'm actually a tortoise."; Grimey Drawer

Munkeymon posted:

The Redux dev tools exhaust memory and I have to close the inspector and reload the page if I try to use them, so I've been debugging with breakpoints like a caveman, but you're correct and changing the assignment to const selectedItems = { ...state.selectedItems }; corrected it, so I can probably change my deselect reducer to just not copy across the deselected properties.

I have a middleware that runs Object.freeze on everything that gets put into the store, to avoid issues like this. I turn it off in production, obviously.

# ? Oct 3, 2018 16:30

FateFree: Nov 14, 2003

High level question for you guys. If you were starting a new SPA from scratch and you wanted to build it nice.. would you choose Vue.js or React? I personally loved Vue for its simplicity but I know React has the market share. And I know that counts for something because my last application was built with a fringe framework which no longer exists, and even though it was technically superior to say Spring MVC at the time, I wish I went with spring just because of the long lasting support and job potential.

I know this is potentially an endless debate so I'm not looking for anything deep, just some points for me to think about.

# ? Oct 3, 2018 17:25

HaB: Jan 5, 2001; What are the odds?

FateFree posted:

High level question for you guys. If you were starting a new SPA from scratch and you wanted to build it nice.. would you choose Vue.js or React? I personally loved Vue for its simplicity but I know React has the market share. And I know that counts for something because my last application was built with a fringe framework which no longer exists, and even though it was technically superior to say Spring MVC at the time, I wish I went with spring just because of the long lasting support and job potential.

I know this is potentially an endless debate so I'm not looking for anything deep, just some points for me to think about.

Vue is gaining enough traction to where I see it on job postings at least once a week, so if you're worried about it disappearing like your previous framework, I don't think that will happen.

# ? Oct 3, 2018 17:33

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

FateFree posted:

High level question for you guys. If you were starting a new SPA from scratch and you wanted to build it nice.. would you choose Vue.js or React? I personally loved Vue for its simplicity but I know React has the market share. And I know that counts for something because my last application was built with a fringe framework which no longer exists, and even though it was technically superior to say Spring MVC at the time, I wish I went with spring just because of the long lasting support and job potential.

I know this is potentially an endless debate so I'm not looking for anything deep, just some points for me to think about.

React. Mainly because I already know and really like React.

# ? Oct 3, 2018 17:40

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

Munkeymon posted:

If I know a DOM subtree can be affected by this global state, but often won't be and I know when it will and won't be, that's a good time to split that subtree out into a (not sure of the right jargon for the following) high-level component with its own reducers and whatnot, right?

Separate reducers are to keep logic separate: they still all populate a single global state object. If you have a component that has a lot of children and you want to avoid checking for re-renders you *may* want to use PureComponent or implement a componentShouldUpdate. I recommend reading this: https://reactjs.org/docs/optimizing-performance.html

# ? Oct 3, 2018 17:48

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Lumpy posted:

Separate reducers are to keep logic separate: they still all populate a single global state object. If you have a component that has a lot of children and you want to avoid checking for re-renders you *may* want to use PureComponent or implement a componentShouldUpdate. I recommend reading this: https://reactjs.org/docs/optimizing-performance.html

Thanks!

# ? Oct 3, 2018 18:20

lunar detritus: May 6, 2009

FateFree posted:

High level question for you guys. If you were starting a new SPA from scratch and you wanted to build it nice.. would you choose Vue.js or React? I personally loved Vue for its simplicity but I know React has the market share. And I know that counts for something because my last application was built with a fringe framework which no longer exists, and even though it was technically superior to say Spring MVC at the time, I wish I went with spring just because of the long lasting support and job potential.

I know this is potentially an endless debate so I'm not looking for anything deep, just some points for me to think about.

Depends on your market. Locally I'm seeing _a lot_ more offers looking for React.

# ? Oct 3, 2018 18:27

my bony fealty: Oct 1, 2008

I would choose React because I know it better, dislike directives in HTML, and because it plays better with GraphQL, in my experience.

# ? Oct 4, 2018 01:46

Vincent Valentine: Feb 28, 2006; Murdertime

FateFree posted:

High level question for you guys. If you were starting a new SPA from scratch and you wanted to build it nice.. would you choose Vue.js or React? I personally loved Vue for its simplicity but I know React has the market share. And I know that counts for something because my last application was built with a fringe framework which no longer exists, and even though it was technically superior to say Spring MVC at the time, I wish I went with spring just because of the long lasting support and job potential.

I know this is potentially an endless debate so I'm not looking for anything deep, just some points for me to think about.

I personally prefer React simply because it's tools and support are so great. I started looking at React from AngularJS a couple of years ago and going from Angular Dev Tools to React Dev Tools sold me on the entire framework. Create-React-App is simply unbeatable for most single-dev spare-time non-commercial apps.

That said, Vue is definitely gaining traction. It's a good framework, and it came at a good time. It first started to come about as an alternative to React when the whole licensing fiasco happened(that has since been resolved), and it's only gotten more and more important from there. I have been looking at every job posting at a particular company I want to work at, and in the past 8 months Angular has dropped from their list of "if you know these frameworks, that's a big plus" entirely, and Vue has moved onto it.

# ? Oct 4, 2018 01:47

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Tools and the whole framework of support surrounding a framework or technology are just as important to me as the technology itself. In fact, thats so important that there are many superior frameworks/technologies/paradigms (like Elm!) that I just don't use because of this.

# ? Oct 4, 2018 02:04

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 04:20

geeves: Sep 16, 2004

Vincent Valentine posted:

I personally prefer React simply because it's tools and support are so great. I started looking at React from AngularJS a couple of years ago and going from Angular Dev Tools to React Dev Tools sold me on the entire framework. Create-React-App is simply unbeatable for most single-dev spare-time non-commercial apps.

I don't know how Angular is these days, but at least AngularJS vs React - React was more simplistic and pretty much a view upon which you could build with other tools once you needed them.

AngularJS was here's 7 different ways of doing the same thing - have fun. Then back tracking and saying to use Directives or BindToController because that's the proper way. When Google then just abandoned the product then stupidly kept using Angular to much confusion just screams that it's a poorer product. (It might not be, but drat you'd think they'd be smarter about branding because it is important)

# ? Oct 4, 2018 03:29

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »