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 »

prom candy: Dec 16, 2005; Only I may dance

Sedro posted:

I think ember-cli is backwards compatible to 1.x, so you can bring your tooling up to date before touching the app. Upgrading the app might be a lot of effort.

Luckily it was already on ember-cli (0.2.7) and ember 1.13. Installing ember-cli 1.13.13 was complaining about node versions so my next step is to see what breaks if I install 2.18 LTS. 1.13 -> 2 was supposed to be a pretty painless upgrade, but we'll see.

# ? Mar 20, 2018 05:19

Adbot: ADBOT LOVES YOU

# ? Jun 8, 2024 15:29

geeves: Sep 16, 2004

my bony fealty posted:

Just learned about Fusebox. Any thoughts? Is it easier/less prone to breaking than Webpack?

I tried fusebox when looking at webpack about a year ago when we were moving to React. I got webpack running in 10 minutes. I couldn't get fusebox working in that amount of time. Webpack took 10 seconds to build on average with varying configurations for uglify and sourcemaps.

I haven't been able to "break" webpack yet. But we will see with Webpack4. I'm not sure the reasoning behind moving the config into package.json, but it's not one I really agree with. But we'll see.

# ? Mar 20, 2018 05:46

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

huhu posted:

Ugh, what am I missing?

Because your SCRIPT tag is a relative path, not an absolute one. You have:

code:

 <script type="text/javascript" src="static/app.bundle.js"></script>

change it to:

code:

 <script type="text/javascript" src="/static/app.bundle.js"></script>

# ? Mar 20, 2018 15:07

huhu: Feb 24, 2006

Lumpy posted:

Because your SCRIPT tag is a relative path, not an absolute one. You have:
code:
 <script type="text/javascript" src="static/app.bundle.js"></script>
change it to:
code:
 <script type="text/javascript" src="/static/app.bundle.js"></script>

I swear I tried this at one point. There was probably 5 different bugs going on at one time conflicting with each other to gently caress my day up. Thank you so so so much.

# ? Mar 20, 2018 15:28

my bony fealty: Oct 1, 2008

geeves posted:

I tried fusebox when looking at webpack about a year ago when we were moving to React. I got webpack running in 10 minutes. I couldn't get fusebox working in that amount of time. Webpack took 10 seconds to build on average with varying configurations for uglify and sourcemaps.

I haven't been able to "break" webpack yet. But we will see with Webpack4. I'm not sure the reasoning behind moving the config into package.json, but it's not one I really agree with. But we'll see.

Ha, I tried switching over a project from Webpack to Fusebox yesterday and had the same experience. It only took me a few minutes to configure Webpack initially; after 15 minutes of Fusebox failing to work I said eh, naw. I'll try again sometime with a fresh project but for now it's Webpack for me. The only real issue I've ever had with it is versioning, and in that case it was the fault of the guide I was following not being updated for newer Webpack versions.

Didn't know about moving config into package. I....don't know about that. I like having them separate. Can't find anything about it though, have anything to read about that?

Guess there's also Parcel now, throw another on the pile.

# ? Mar 20, 2018 15:53

The Fool: Oct 16, 2003

Kobayashi posted:

I decided to play around with Docker today. I'm sure it's cool but it's darkly humorous to me that within an hour of starting I was using one syntax for the Dockerfile (sentence-case, extension-free), another for docker-compose.yml (standard filename), and a third for .dockerignore (system file). This seems needlessly brittle, especially when it comes to shared values like ports to expose or paths. Do I really just need to copy and paste across these files (and my project files) or is there a better way to glue everything together?

The Dockerfile defines the container image you are going to run.

The docker-compose.yml file is for settings while running the container. Basically everything you define in docker-compose you should be able to instead define in the command line if you so choose.

# ? Mar 20, 2018 18:17

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

huhu posted:

I swear I tried this at one point. There was probably 5 different bugs going on at one time conflicting with each other to gently caress my day up. Thank you so so so much.

Simple bugs are quantum in nature. They can only be detected when someone else looks at them.

# ? Mar 20, 2018 18:55

prom candy: Dec 16, 2005; Only I may dance

Netlify launched lambda support: https://www.netlify.com/blog/2018/03/20/netlifys-aws-lambda-functions-bring-the-backend-to-your-frontend-workflow/

We recently deployed a gatsby site on Netlify and it's a very nice system. Being able to easily connect front ends to Serverless functions is potentially huge.

# ? Mar 21, 2018 04:40

Vincent Valentine: Feb 28, 2006; Murdertime

Lumpy posted:

Simple bugs are quantum in nature. They can only be detected when someone else looks at them.

If I had a nickel for every time I struggle with something and then someone else spots my typo immediately...

# ? Mar 21, 2018 11:34

Kobayashi: Aug 13, 2004; by Nyc_Tattoo

Spraynard Kruger posted:

I don't think these things usually involve much copying and pasting across them... The Dockerfile defines how to build the image (start with a Node base image, install my npm packages, put app code here, etc). The docker-compose.yml file is an optional, more structured way to store your development settings. And .dockerignore is just like .gitignore, a simple list to define what shouldn't be put inside your Docker image (like your .git folder, maybe your node_modules or Python virtualenv, etc).

The Fool posted:

The Dockerfile defines the container image you are going to run.

The docker-compose.yml file is for settings while running the container. Basically everything you define in docker-compose you should be able to instead define in the command line if you so choose.

Fair enough. Maybe I�m not using Docker for its intended purpose, but I tend to pick up projects then abandon them for months at a time, after which the Javascript universe has changed � new Node fork, new NPM replacement, new OSX version changed everything, etc. I thought Docker might be a good way to abstract over some of that churn.

Almost out of the box I�m mounting directories so I can do live code development in Docker containers. That means copying path names between the Dockerfile and docker-compose.yml. Then, I already had port settings for my app in a config file, so I have to copy those values to docker-compose.yml. Then .dockerignore starts looking a lot like .gitignore (but not exactly). The end result is I miss one slash or colon somewhere across a dozen various configuration files and it�s off to a Google to try to debug.

# ? Mar 21, 2018 16:09

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

Kobayashi posted:

Almost out of the box I�m mounting directories so I can do live code development in Docker containers. That means copying path names between the Dockerfile and docker-compose.yml. Then, I already had port settings for my app in a config file, so I have to copy those values to docker-compose.yml. Then .dockerignore starts looking a lot like .gitignore (but not exactly). The end result is I miss one slash or colon somewhere across a dozen various configuration files and it�s off to a Google to try to debug.

Having been in your shoes I want to mention real quick that, if you decide to use Docker Compose (which I support), you may not even need a separate Dockerfile. A big trick to making Docker integration painless is to dig into the various images available on the Docker Hub (or is it Docker Store now?) and learn each image's "API". If, for example, you use the official Node image, its "how to use this" documentation makes it clear that mounting the folder containing your app's code to /home/node/app is enough to enable livereloading within the container. Other containers, like the Postgres one, allow you to specify a username and password with specific env variables you define in docker-compose.yml (or, even better, a separate file that you add in with the env_file property).

In these situations, unless you're doing anything really weird, your Dockerfile can be reduced to a single image: "node:8" line in your Docker Compose config.

Also, on the topic of duplicated port settings, why not make that port setting an environment variable you define in docker-compose.yml, then refactor your app to read that environment variable? That'd address the duplication effort, especially since you can refactor your docker-compose to use environment variables to then expose that port within a ports entry.

I'm a huge fan of Docker but it's not without its learning curve. Good luck, hope that helps.

# ? Mar 21, 2018 16:36

Dominoes: Sep 20, 2007

Hey dudes: Looking for wisdom on create-react-app, and what it does. Context: I've built a webapp using Django+React before; used a kludgy approach of passing serialized models/data o the JS using a template. I'm now trying a rest-framework approach on a new-app. Create-react-app is a popular, official way to create React frontend project.

CRA installs react and accessories; but I can just do that with yarn add react react-dom redux react-redux

It generates a webpack config, which needs to be almost entirely rewritten to work with Typescript. Creates a node server; not sure why this is relevant, given React is for front-end work.

It creates an App.js file, which appears to be JSX despite the extension, and misc files to go with it.

Overall, I'm confused since the overlap between what create-create-app sets up, and what I understand I need to link with a REST backend using Typescript and React, is a few node packages.

Ie, this is what I'd actually want as new-package boilerplate:
index.html:

code:

<!DOCTYPE html>
<html>
    <head>
     ...
    <body>
        <div id="react"></div>

        <!-- Dependencies -->
        <script src="./node_modules/react/umd/react.development.js"></script>
        <script src="./node_modules/react-dom/umd/react-dom.development.js"></script>

        <!-- Main -->
        <script src="./dist/main.js"></script>
    </body>
</html>

A practical hello world / boilerplate:

index.txs

code:

import * as React from 'react'
import * as ReactDOM from 'react-dom'
import { Provider, connect } from 'react-redux'
import {createStore, Store, combineReducers} from 'redux'

const Main = ({store}: {store: any}) => {

    return (
        <div>
            <h1>Hello World</h1>
        </div>
    )
}



// State and initialization below this line.

const initialState = {
}

const mainReducer = (state=initialState, action: any) => {
    // Misc config variables not related to the current schedule.
    switch (action.type) {
        case 'changePage':
            return {...state, page: action.Page}
    }
}


let reducer = combineReducers({
    main: mainReducer,
})

const store: Store<any> = createStore(reducer)


// Connext the redux store to React.
const mapStateToProps = (state) => ({ store: state })
const Connected = connect(mapStateToProps)(Main)


ReactDOM.render(
    <Provider store={store}>
        <Connected />
    </Provider>, document.getElementById('react')
)

webpack.config.js:

code:

module.exports = {
    entry: {
        main: "./src/main.tsx",
     },
    output: {
        filename: "[name].js",
        path: __dirname + "/dist"
    },

    // Enable sourcemaps for debugging webpack's output.
    devtool: "source-map",

    resolve: {
        // Add '.ts' and '.tsx' as resolvable extensions.
        extensions: [".ts", ".tsx", ".js", ".json", ".d.ts"]
    },

    module: {
        rules: [
            // All files with a '.ts' or '.tsx' extension will be handled by 'awesome-typescript-loader'.
            { test: /\.tsx?$/, loader: "awesome-typescript-loader" },

            // All output '.js' files will have any sourcemaps re-processed by 'source-map-loader'.
            { enforce: "pre", test: /\.js$/, loader: "source-map-loader" }
        ]
    },

    // When importing a module whose path matches one of the following, just
    // assume a corresponding global variable exists and use that instead.
    // This is important because it allows us to avoid bundling all of our
    // dependencies, which allows browsers to cache those libraries between builds.
    externals: {
        "react": "React",
        "react-dom": "ReactDOM"
    }
}

Dominoes fucked around with this message at 18:14 on Mar 21, 2018

# ? Mar 21, 2018 16:45

porksmash: Sep 30, 2008

create-react-app my-app --scripts-version=react-scripts-ts (from https://github.com/wmonk/create-react-app-typescript). I don't think anyone cares these days about js vs jsx file extensions.

# ? Mar 21, 2018 17:08

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

Dominoes posted:

Hey dudes: Looking for wisdom on create-react-app, and what it does.

Lets you set up most everything you need for a React app (using typescript or not) with hot-reloading dev server, testing, and building a production app by typing one thing, rather than typing many things, and knowing it's set up properly and will be updated for you.

# ? Mar 21, 2018 17:11

Dominoes: Sep 20, 2007

I wonder if my gap in understanding is about the dev server; I've been looking at the front end part as simply a mostly-empty HTML file, modern JS files, and a framework to compile them to browser-compatible ones.

porksmash posted:

create-react-app my-app --scripts-version=react-scripts-ts (from https://github.com/wmonk/create-react-app-typescript). I don't think anyone cares these days about js vs jsx file extensions.

It looks like this doesn't configure webpack, which is required if you need imports; ie any nontrivial project. (ie tsc alone doesn't bundle) This official TS guide has worked for me.

Dominoes fucked around with this message at 17:44 on Mar 21, 2018

# ? Mar 21, 2018 17:34

porksmash: Sep 30, 2008

The dev server is there to provide helpful debugging information, hot module reloading, and saves you from running npm build and opening index.html in a browser every time you want to see what you wrote work. How do you currently write frontend code?

edit:

Dominoes posted:

It looks like this doesn't configure webpack, which is required if you need imports; ie any nontrivial project. (ie tsc alone doesn't bundle)

Did you look at the create-react-app documentation? These are questions that are already answered, and not related to whether or not you're using typescript. In any case it's just a tool and if it doesn't fit your use case then don't use it.

porksmash fucked around with this message at 17:47 on Mar 21, 2018

# ? Mar 21, 2018 17:40

Dominoes: Sep 20, 2007

porksmash posted:

How do you currently write frontend code?

My only existing modern-JS project is tightly integrated with the backend, using sparse templates that call JS files compiled with webpack/tsc, pass JSON from views, and fetch calls to send POST data and receive responses. I'm inexperienced with REST-style separation.

Dominoes fucked around with this message at 18:01 on Mar 21, 2018

# ? Mar 21, 2018 17:46

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

Dominoes posted:

I wonder if my gap in understanding is about the dev server; I've been looking at the front end part as simply a mostly-empty HTML file, modern JS files, and a framework to compile them to browser-compatible ones.

It looks like this doesn't configure webpack, which is required if you need imports; ie any nontrivial project. (ie tsc alone doesn't bundle)

It absolutely does, as I literally started a typescript based create-react-app on Sunday to start learning typescript. It seems you are looking for reason to hate c-r-a, so my suggestion is to not use it then maybe?

The dev server bundles your JS and serves it from memory from an in-memory HTML file and rebundles / refreshes the browser when you make a change to your JS/TS code. That's it.

# ? Mar 21, 2018 18:32

prom candy: Dec 16, 2005; Only I may dance

I've been using CRA with Typescript since September with very few complaints but one of my favourite things is when someone who's spent 5 minutes with an extremely popular tool comes in to talk about how it's useless, so please proceed.

# ? Mar 21, 2018 19:33

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.

whyyyyyy is my parent to child component communication suddenly not working when I use *ngIf instead of [hidden] I understand what happens when we use these, hidden is hidden, and ngIf makes the component template simply not exist when its set.

I'm using @ViewChild to view the child component and then attaching poo poo to it like so:

code:

<child-component-selector #childComponentTag></child-component-selector>

code:

import {AllThatGayDumbAngular2Shit, ViewChild, Input, Output} from @angular.fart;

@Component ({
selector: 'daddy-selector',
template 'dad.component.html'
})

export class ParentComponent {

@ViewChild('childComponentTag') childComponentObject: ChildComponentComponent;

public childComponentToggle = false;

public childMethodActivator(value: any) {
public childComponentToggle = true;
this.childComponent.childMethod(value);
}

}

code:

import {AllThatGayDumbAngular2Shit, ViewChild, Input, Output} from @angular.fart;

@Component ({
selector: 'child-component-selector',
template 'child-component-selector.component.html'
})

export class ChildComponentComponent {

public thingWeWantToPopulateFromParent: string;

@Input() childMethod(value: any) {
this.thingWeWantToPopulateFromParent = value;
}

code:

<div id="childComponentTemplate [hidden]="childComponentToggle">{{thingWeWantToPopulateFromParent}}</div>

When we do this it works fine because the child component template is rendered but it isn't in view. Obviously this is not necessarily efficient because the code is running in the background without us using it if we don't use it. When we change it to *ngIf the component exists and is called only when we want it. The problem is that the child component is not accepting the parent parameters when we try to pass them through even though the order of operations is syntactically correct?

tl;dr:

Parent -> Child = OK! if Child template is [hidden].
Parent -> Child = NO OK! if Child template is *ngIf.

Parent -> Child Property/Method is always populated after *ngIf or [hidden] is set via boolean value.
They should work perfectly fine as the [hidden] templates properties are populated at any time as the [hidden] template's component always exists. The *ngIf's properties SHOULD be populated perfectly fine as the *ngIf's template & component are spawned before we attempt to populate them.

What did I do wrong?

Ape Fist fucked around with this message at 23:59 on Mar 21, 2018

# ? Mar 21, 2018 21:04

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

Ape Fist posted:

What did I do wrong?

Not sure why it doesn't work, but have you tried to implement it by binding the Input value in the parent template instead, to see if ViewChild is what's causing the problem?

code:

// dad.component.html
<child-component-selector *ngIf="childComponentToggle" [childValue]="getChildValue()">

code:

// dad.component.ts
export class ParentComponent {
  public childComponentToggle = false;

  public getChildValue() {
    ...
  }
}

code:

export class ChildComponent {
  @Input() public childValue;
}

You may get some issues with the change detection, depending on how the value you're sending to the child component is retrieved. If it's a value you need to get asynchronously the standard way to do it would be to have it as an observable and use the async pipe in the parent component template.

My experience is that life gets a lot easier if all communication between components happens with just @Input and @Output, but I'm sure there are situations where that's difficult.

# ? Mar 22, 2018 08:53

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.

Yeah that worked.

# ? Mar 22, 2018 19:30

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

I have a quick question about using the spread operator with React's setState method.

Is is okay to do something like this? I only ask because I'm trying to troubleshoot something, and I have a feeling this syntax might be the cause of a big issue.

JavaScript code:

this.state{
  subject: "hello!!!!",
  body: "I am okay today!!",
  signature: "HelloWorld Inc"
}

const myObject = {
  subject: "hello world",
  body: "how are you"
}

this.setState({...myObject});

teen phone cutie fucked around with this message at 19:37 on Mar 22, 2018

# ? Mar 22, 2018 19:35

Love Stole the Day: Nov 4, 2012; Please give me free quality professional advice so I can be a baby about it and insult you

Grump posted:

I have a quick question about using the spread operator with React's setState method.

Is is okay to do something like this? I only ask because I'm trying to troubleshoot something, and I have a feeling this syntax might be the cause of a big issue.
JavaScript code:
this.state{
  subject: "hello!!!!",
  body: "I am okay today!!",
  signature: "HelloWorld Inc"
}

const myObject = {
  subject: "hello world",
  body: "how are you"
}

this.setState({...myObject});

I think what you want to do is this:

JavaScript code:

this.setState(... this.state, myObject);

# ? Mar 22, 2018 19:59

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

Grump posted:

I have a quick question about using the spread operator with React's setState method.

Is is okay to do something like this? I only ask because I'm trying to troubleshoot something, and I have a feeling this syntax might be the cause of a big issue.
JavaScript code:
this.state{
  subject: "hello!!!!",
  body: "I am okay today!!",
  signature: "HelloWorld Inc"
}

const myObject = {
  subject: "hello world",
  body: "how are you"
}

this.setState({...myObject});

Why not just try it out in the console? :v:

That *should* work though, but it's completely pointless. You can just do this:

JavaScript code:

this.setState( myObject );

And it will do the exact same thing. The only reason you'd want to use the spread operator is to return a copy of something (and maybe modify it in the process), and you have no reason to do that here.

# ? Mar 22, 2018 20:00

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

Love Stole the Day posted:

I think what you want to do is this:
JavaScript code:
this.setState(... this.state, myObject);

That won't work. It will throw a syntax error I think, because you can't just have a bare spread operator like that. (I could be mistaken though!)

setState will handle merging for him, there is no need to reference the "old" state at all if you are updating keys like he is. About the only time you need to use the spread operator with setState is if you are updating nested stuff or you want to add an item to an array:

JavaScript code:

const initialState = { items: [1,2], cow: "bell" };
this.setState( initialState );

const newItem = 43;
this.setState({
   items: [...this.state.items, newItem]
})
// state is now: {items: [1,2,43], cow:"bell"}

EDIT: in Redux, where you are doing your *own* updates in reducers, you need / want to use the spread operator to update without mutating:

code:

const initalState = {a: 1, b: 2}
const reducer = (state=initialState , action) => {
  return {
    ...state,
    b: 8
  };
}
const newState = reducer(); // newState =  {a: 1, b: 8} , initialState not changed.

Lumpy fucked around with this message at 20:15 on Mar 22, 2018

# ? Mar 22, 2018 20:06

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

Lumpy posted:

Why not just try it out in the console?

yeah. It works but sometimes I'll refresh the page and it won't work, so I've been pulling my hair out for the past 4 hours at work and just wanted assurance that I'm not going insane.

Basically, we have an app that has this flow

open modal > make request to get data > update state with that data

and it works most of the time, but sometimes I'll refresh and try again and it does the above only when the modal is closed (despite there being no events tied to modal close, with the exception of setting isOpen to false).

really frustrating

e: Nvm. The issue is that React devtools are showing me incorrect information

teen phone cutie fucked around with this message at 20:30 on Mar 22, 2018

# ? Mar 22, 2018 20:23

prom candy: Dec 16, 2005; Only I may dance

setState handles merging for you and you can safely use the spread operator in setState if you want to. setState will not do deep merges for you though.

console.log everything when you're having weird issues, or set breakpoints (or both)

# ? Mar 23, 2018 00:08

smackfu: Jun 7, 2004

How do people handle live deployments where a feature requires compatible private API and front end changes? We have all the dev ops stuff worked out, so people stay logged in and there is no outage. But they are still running the old version of our SPA against the new backend until they refresh the page somehow. Do you version your private API just to handle that short time period? Or just try very hard not to change API?

Doing deployments at night and just logging everyone out avoided this problem nicely since it forced everyone to refresh the front end.

# ? Mar 23, 2018 10:54

prom candy: Dec 16, 2005; Only I may dance

Similar to databases I think it's possible to make your first change backwards compatible and then roll out a second change afterwards that's your best bet. You can also maybe do blue-green deploys where you deploy the whole new system and then change the IPs? Somebody who's smarter at devops might have a better answer.

# ? Mar 23, 2018 18:09

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Trying to debug mocha unit tests that hang after completion, I can't find anything online about it that aren't obvious things I haven't already looked at. Using async and await.

code:

const db = require('../../../db');
const method = require('../../../methods/user/create');

const createUser = async (attrs) => {
    const data = Object.assign({
        id: uuid.v4(),
        passwordHash: '1234567890',
        address
    }, attrs);
    await db('users').insert(data);
    return data;
};

// FIXME: why the hell does this hang the test suite

describe.only('/methods/user/create', () => {
    describe('user exists', () => {
        it('should send user-exists email if verified', async () => {
            const data = await createUser({ isVerified: true });
            await method({ address: data.address, password });
        });
    });
});

There are no assertions in this example because when I remove the assertions the thing still hangs. All of the tests complete which means my async functions are finishing and the assertions all pass. Then it hangs saying "1 passing (266ms)" and sits there.

Been driving me crazy all day.

# ? Mar 23, 2018 19:14

ynohtna: Feb 16, 2007; backwoods compatible; Illegal Hen

I'm probably remembering this wrong, but I think you have to call a done() method when an asynchronous test completes in mocha.

# ? Mar 23, 2018 19:18

abraham linksys: Sep 6, 2010

Nolgthorn posted:

There are no assertions in this example because when I remove the assertions the thing still hangs. All of the tests complete which means my async functions are finishing and the assertions all pass. Then it hangs saying "1 passing (266ms)" and sits there.

could be some kind of long-lived connection/event listener preventing node from stopping? i don't think your database connection would be an issue, but something in that regard?

potentially useful is one of my favorite-named npm packages ever https://github.com/myndzi/wtfnode

# ? Mar 23, 2018 19:22

Doh004: Apr 22, 2007; Mmmmm Donuts...

smackfu posted:

How do people handle live deployments where a feature requires compatible private API and front end changes? We have all the dev ops stuff worked out, so people stay logged in and there is no outage. But they are still running the old version of our SPA against the new backend until they refresh the page somehow. Do you version your private API just to handle that short time period? Or just try very hard not to change API?

Doing deployments at night and just logging everyone out avoided this problem nicely since it forced everyone to refresh the front end.

Versioned APIs are important and you shouldn't be breaking that contract with live code. If you're making breaking changes (different endpoints, properties having their names changed) and not providing backwards support, you're doing it wrong.

That said, perhaps you could have a client "version" number that's passed along as a header in your API requests, and have your backend service return a specific status/response if your client's version is too old and needs to refresh. Then, in your client's networking code, have a standardize way to alert the user that they need to refresh their page (a link or something).

I've never done this with a SPA before, but I imagine that could work.

# ? Mar 23, 2018 20:55

Dominoes: Sep 20, 2007

Lumpy posted:

It absolutely does, as I literally started a typescript based create-react-app on Sunday to start learning typescript. It seems you are looking for reason to hate c-r-a, so my suggestion is to not use it then maybe?

The dev server bundles your JS and serves it from memory from an in-memory HTML file and rebundles / refreshes the browser when you make a change to your JS/TS code. That's it.

Got it working; just needed to drop my webpack config in, and replace/edit the other config files. The auto-refreshing's nice.

# ? Mar 23, 2018 21:09

ddiddles: Oct 21, 2008; Roses are red, violets are blue, I'm a schizophrenic and so am I

ynohtna posted:

I'm probably remembering this wrong, but I think you have to call a done() method when an asynchronous test completes in mocha.

You do have to call done() with async tests, but you should get an angry error message if a test times out because of async.

Or maybe I'm thinking of Gulp?

# ? Mar 24, 2018 01:03

Sedro: Dec 31, 2008

ynohtna posted:

I'm probably remembering this wrong, but I think you have to call a done() method when an asynchronous test completes in mocha.

It also works to return a promise (which it does by making it async)

# ? Mar 24, 2018 01:34

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

ddiddles posted:

You do have to call done() with async tests, but you should get an angry error message if a test times out because of async.

Or maybe I'm thinking of Gulp?

That must be gulp, mocha will just say it timed out.

# ? Mar 24, 2018 02:57

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

abraham linksys posted:

could be some kind of long-lived connection/event listener preventing node from stopping? i don't think your database connection would be an issue, but something in that regard?

potentially useful is one of my favorite-named npm packages ever https://github.com/myndzi/wtfnode

It seems like, using this tool, and I could be wrong... is it possible, that a library as large and as popular as knexjs is the culprit? I would love to say no but when I inspect this it seems like knexjs leaves an open socket and one of its dependencies leaves a running interval.

What the heck??

God I feel like I hate this industry sometimes.

# ? Mar 25, 2018 04:13

Adbot: ADBOT LOVES YOU

# ? Jun 8, 2024 15:29

my bony fealty: Oct 1, 2008

Does anyone have a Windows bash client they particularly like? I tried out Hyper and it's great except for the fatal flaw that killing a server or webpack watch via keyboard doesn't work. Well, sometimes it does...after hanging for several minutes. I'm using git bash with it which by itself does not have that problem.

# ? Mar 25, 2018 04:24

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

«‹›235 »