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 »

Kekekela: Oct 28, 2004

Grump posted:

here it is

http://contact.meteorapp.com/

user ljkrebs approves

# ? May 16, 2017 22:36

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 22:13

The Fool: Oct 16, 2003

Grump posted:

here it is

http://contact.meteorapp.com/

Will this get me more interviews?

Viewing on mobile, your sign in modal is off center and cut off on the right.

# ? May 16, 2017 23:05

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

Grump posted:

here it is

http://contact.meteorapp.com/

Will this get me more interviews?

Congrats!

The phone number format restriction might not work so well for international phone numbers

# ? May 16, 2017 23:18

Odette: Mar 19, 2011

Grump posted:

here it is

http://contact.meteorapp.com/

Will this get me more interviews?

Get a HTTPS cert from Let's Encrypt. They're free.

# ? May 16, 2017 23:20

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

The Fool posted:

Viewing on mobile, your sign in modal is off center and cut off on the right.

Yeah i caught that. That login form was a built in thing with Meteor. You'd think it would look good out of the box :shrug:

Also got to add some margins in some places and make the submit buttons have the same styling on mobile

fletcher posted:

Congrats!

The phone number format restriction might not work so well for international phone numbers

International numbers might work. It just might be the error message that's wrong. I'll have to double check

teen phone cutie fucked around with this message at 23:41 on May 16, 2017

# ? May 16, 2017 23:39

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

Please tell me my dumb idea is dumb. Or, maybe it's not so dumb? I am thinking of doing vertical whitespace in an app as a React component. So instead of a Header or NavBar or whatever getting CSS margins to put vertical whitespace between it and the next element, I'd have some sort of Spacer component:

HTML code:

<SomeLargerComponent>
   <HeaderBar />
   <Spacer type="large" />
   <Header>
      What a dumb idea!
   </Header>
   <Spacer type="medium" />
   <BodyCopy>
       Why on earth would I do this?
   </BodyCopy>
   <Spacer type="small" />
   <Button />
</SomeLargerComponent>

Then the spacer can have a media query for getting smaller on small screens, and I can compose away without worrying about special snowflake CSS rules for vertical whitespace. Thoughts?

# ? May 17, 2017 17:20

luchadornado: Oct 7, 2004; A boombox is not a toy!

My first thought on hearing any idea good or bad, is to define the problem: you need vertical whitespace in your layouts. Identify a few solutions - one or two should come to mind immediately. I force myself to come up with 3 or more, regardless of how ridiculous they are.

Then I identify and strip out all emotion from the description of the problem and proposed solutions: "special snowflake CSS rules for vertical whitespace" turns into "CSS rules for vertical whitespace". Natural inclination for most people is to be critical, so start there and ask yourself "what is so bad about CSS rules for vertical whitespace?" poo poo, come up with a list of things if you need to. What's good about it, what value are you anticipating?

Then I try to turn it around and instead of saying "ugh, here's why this won't work" I say "well how could I make this work?". Come up with a list of pros and cons again.

In this specific case I almost wouldn't go through the exercise because there are certain rules that I let trump everything almost all of the time. The best code is code you don't have to write. If you put this in React, it's code that then should be unit tested and then QA'd. Automated tests for builds could fail on it and hold up builds. You now have another dependency on React that you'll need to handle if you ever want to upgrade or move away. Whitespace isn't a show stopper for most apps, so you'll have some acceptance tests that might even be manual. If the CSS doesn't work right, your whitespace looks bad. If the React code breaks, your entire page might not even render. That's a huge risk that you just incurred, and you need to weigh that against the value you think you're getting.

Just some of the poo poo I think about regardless of whether it's what day of the week to subtask stories for a sprint, or how to architect a stream processor that handles 100k messages/second.

luchadornado fucked around with this message at 12:57 on May 18, 2017

# ? May 18, 2017 03:04

PlaneGuy: Mar 28, 2001; g e r m a n
e n g i n e e r i n g; Yam Slacker

Helicity posted:

My first thought on hearing any idea good or bad, is to define the problem: you need vertical whitespace in your layouts. Identify a few solutions - one or two should come to mind immediately. I force myself to come up with 3 or more, regardless of how ridiculous they are.

<snip>

everything here is gold for all developers everywhere

so, out of curiousity, what's so snowflake about https://jsfiddle.net/f9fLud5v/4/?

# ? May 23, 2017 22:00

Kekekela: Oct 28, 2004

Guys I added logrocket to my redux point of sale app today and my mind is straight up blown. Basically video playback of every user session with your api calls and redux events right there in separate panes, with super simple setup and JIRA integration. I feel like I'm in a dream.

e: Note that you don't need to use redux for it to be awesome, that's just gravy...i want to shout about this from the rooftops right now

# ? May 25, 2017 23:11

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

Can anyone have a look at this TSX table component and tell me why my table rows aren't rendering? The renderRow() and renderGrade functions are running (the logging statements run), but the table rows are not showing up in the DOM.

JavaScript code:

import * as RX from 'reactxp';
import Grader from '../appUtilities/Grader'
 
 
const styles = {
 
}
const rows = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
 
interface ComponentChartProps {
    questionType: string;
}
 
class ProgressChart extends RX.Component<ComponentChartProps, null> {
 
    render() {
        return (
            <RX.View>
                <RX.Text>Progress Report for {this.props.questionType}</RX.Text>
                <table>
                    {this.renderTableBody()}
                </table>
            </RX.View>
        )
    }
 
    renderTableBody(): JSX.Element {
        return (
            <tbody>
                <tr>
                    <td></td>
                    <td>1</td>
                    <td>2</td>
                    <td>3</td>
                    <td>4</td>
                    <td>5</td>
                    <td>6</td>
                    <td>7</td>
                    <td>8</td>
                    <td>9</td>
                    <td>10</td>
                </tr>
                {rows.map((row, index) => {
                    this.renderRow(row, index);
                })}
            </tbody>
        )
    }
    renderRow(b: number, index: number): JSX.Element {
        console.log("Rendering row " + b);
 
        return (
            <tr>
                <td>{b}</td>
                {rows.map((row, rowIndex) => {
                    this.renderGrade(row, b, rowIndex);
                })}
            </tr>
        )
    }
    renderGrade(a: number, b: number, index: number): JSX.Element {
        console.log("\tRendering grade " + a + ", " + b);
 
        return (
            <td>
                {/*{(Grader.Grade(this.props.questionType, a, b).toString())}?*/}
            </td>
        )
    }
}
 
 
export default ProgressChart;

You can see it live for yourself here by typing a question mark (eg, as you would to bring up the keyboard shortcuts in gmail).

This is turning into one of those real hair-pulling moments, which is bad, since I'm running out of hair.

edit: Blah. I have it now. Needed return statements inside my maps, like so:

JavaScript code:

{rows.map((row, index) => {
    return this.renderRow(row, index);
})}

Newf fucked around with this message at 23:41 on May 28, 2017

# ? May 28, 2017 23:32

Dogcow: Jun 21, 2005

You can also do this:

JavaScript code:


{rows.map((row, index) => this.renderRow(row, index))}

If you omit the curly braces the return statement is implied.

# ? May 29, 2017 00:14

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

Dogcow posted:

You can also do this:
JavaScript code:
{rows.map((row, index) => this.renderRow(row, index))}
If you omit the curly braces the return statement is implied.

sonofa...

Thanks

# ? May 29, 2017 01:17

Honest Thief: Jan 11, 2009

Would socket.io be the most appropriate solution for real time events, for a C# backend and React frontend? The current solution has the flux stores on a loop checking the the "push" notification status, and I wanted to change that.

# ? May 30, 2017 10:54

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

K got another "general opinion" sort of question.

I am working on my first actual real-world Angular 4 app. I'm thinking the question probably applies to React as well, since they have some similarities.

When it comes to Components - what's your overall approach to designing them and perhaps breaking them up into smaller ones? How big is too big?

For example, I am working on a feature to display a list of items assigned to the currently logged in user. Basically a table with a banner at the top displaying some overall information, a tool bar, a filter bar at the top of the table, and the table itself. For my initial pass, the Banner is a component and the Toolbar is one as well. I keep waffling on the filter bar, and I don't think I have a good reason to. Chances are excellent it won't ever be used anywhere else - so if reusability is my driving principle, it fails right away. But if it's part of the table, the table component itself is getting somewhat large.

Elsewhere in the application, anything I use more than once has been broken out, but this is the largest feature I have written so far, so I'm wondering at what point the size will render something difficult/annoying to maintain going forward. So far, I have been building entire screens, getting them working, then breaking up into components as needed.

Really just looking for general approaches.

# ? May 30, 2017 13:28

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

HaB posted:

K got another "general opinion" sort of question.

I am working on my first actual real-world Angular 4 app. I'm thinking the question probably applies to React as well, since they have some similarities.

When it comes to Components - what's your overall approach to designing them and perhaps breaking them up into smaller ones? How big is too big?

For example, I am working on a feature to display a list of items assigned to the currently logged in user. Basically a table with a banner at the top displaying some overall information, a tool bar, a filter bar at the top of the table, and the table itself. For my initial pass, the Banner is a component and the Toolbar is one as well. I keep waffling on the filter bar, and I don't think I have a good reason to. Chances are excellent it won't ever be used anywhere else - so if reusability is my driving principle, it fails right away. But if it's part of the table, the table component itself is getting somewhat large.

Elsewhere in the application, anything I use more than once has been broken out, but this is the largest feature I have written so far, so I'm wondering at what point the size will render something difficult/annoying to maintain going forward. So far, I have been building entire screens, getting them working, then breaking up into components as needed.

Really just looking for general approaches.

I would probably leave it as a part of the thing it's filtering for now, it should make your inter-component communication much simpler. If you run into a reusablility issue later on, deal with it then.

Honest Thief posted:

Would socket.io be the most appropriate solution for real time events, for a C# backend and React frontend? The current solution has the flux stores on a loop checking the the "push" notification status, and I wanted to change that.

Socket.io is a good candidate for handling push notifications. Your current solution is awful, even just using raw Websockets would be better.

# ? May 30, 2017 16:39

Honest Thief: Jan 11, 2009

Skandranon posted:

I would probably leave it as a part of the thing it's filtering for now, it should make your inter-component communication much simpler. If you run into a reusablility issue later on, deal with it then.

Socket.io is a good candidate for handling push notifications. Your current solution is awful, even just using raw Websockets would be better.

It's what got handed down to me, it is what it is.
I'd have to talk to the backend guy to implement it on his side as well, so I was hoping there wasn't any restriction in implementing with socket.io, mainly because I did it once with node and react so it would be simpler on my end.

# ? May 30, 2017 16:46

MrMoo: Sep 14, 2000

Skandranon posted:

Socket.io is a good candidate for handling push notifications. Your current solution is awful, even just using raw Websockets would be better.

SSE is there for push but there is almost no way it is less work than implementing in WebSockets and it comes with more overhead too, pretty much a DoA technology.

# ? May 30, 2017 16:47

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

MrMoo posted:

SSE is there for push but there is almost no way it is less work than implementing in WebSockets and it comes with more overhead too, pretty much a DoA technology.

I really don't like SSE because you can't actually attach a callback to ALL messages, you MUST subscribe to certain keys. This makes it hard to inspect the general stream and find out if the backend has a typo in the messages it is sending.

# ? May 30, 2017 17:18

Doc Hawkins: Jun 15, 2010; Dashing? But I'm not even moving!

Skandranon posted:

I really don't like SSE because you can't actually attach a callback to ALL messages, you MUST subscribe to certain keys. This makes it hard to inspect the general stream and find out if the backend has a typo in the messages it is sending.

I thought you could, with onmessage().

# ? May 30, 2017 17:24

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Doc Hawkins posted:

I thought you could, with onmessage().

I remember trying that and it failing spectacularly, but I can't remember why. Possibly because you can't use alongside addEventListener().

# ? May 30, 2017 17:47

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

HaB posted:

K got another "general opinion" sort of question.

I am working on my first actual real-world Angular 4 app. I'm thinking the question probably applies to React as well, since they have some similarities.

When it comes to Components - what's your overall approach to designing them and perhaps breaking them up into smaller ones? How big is too big?

For example, I am working on a feature to display a list of items assigned to the currently logged in user. Basically a table with a banner at the top displaying some overall information, a tool bar, a filter bar at the top of the table, and the table itself. For my initial pass, the Banner is a component and the Toolbar is one as well. I keep waffling on the filter bar, and I don't think I have a good reason to. Chances are excellent it won't ever be used anywhere else - so if reusability is my driving principle, it fails right away. But if it's part of the table, the table component itself is getting somewhat large.

Elsewhere in the application, anything I use more than once has been broken out, but this is the largest feature I have written so far, so I'm wondering at what point the size will render something difficult/annoying to maintain going forward. So far, I have been building entire screens, getting them working, then breaking up into components as needed.

Really just looking for general approaches.

Everything I've read on the topic emphasizes that components should be as concise and specific in scope as possible so that they could potentially re-used elsewhere in the future. That way everything is kept modular.

Don't take my word as gospel though. I'm just a wannabe.

# ? May 30, 2017 19:44

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

Now that I have some experience messing around with create-react-app, I'm starting to do more research in what the gently caress these dependencies are actually doing. I see that webpack is doing the bundling and babel is doing the transpiling.

But I was taking a look at the app we're currently building at my job, and the dependencies list webpack, babel, gulp, and browserify and I'm trying to wrap my head around what the gently caress each of these things is actually doing. After doing some research, this configuration kinda sounds redundant and seems like we don't need all 4.

So I guess what I'm asking is

1) Do webpack and babel do anything major other than bundle and transpile? And is webpack responsible for setting up the local server when you run a create-react app? How does that work?
2) What exactly are Gulp and Browserify? Are they just not-as-powerful versions of babel and webpack? Gulp's official website isn't really good at explaining what is actually does.

There's just so many things that go into these libraries and I really feel uncomfortable using dependencies without knowing what they're actually doing for me.

# ? Jun 3, 2017 05:00

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Grump posted:

1) Do webpack and babel do anything major other than bundle and transpile? And is webpack responsible for setting up the local server when you run a create-react app? How does that work?

Babel just transpiles. You are not writing JavaScript, you are writing Babel. JavaScript is your bytecode. Same with TypeScript.

Webpack just bundles (but can do a lot of bundling stuff). You may be using a webserver hosted by Webpack, but you do not have to, you could use any number of webservers with Webpack

Grump posted:

2) What exactly are Gulp and Browserify? Are they just not-as-powerful versions of babel and webpack? Gulp's official website isn't really good at explaining what is actually does.

Gulp is a generic build system tool, where you define tasks to be run with JavaScript code. It is more flexible than Grunt. It may or may not be superfluous depending on how you are using Webpack/Babel.

Browserify is basically an older version of Webpack, they do the same thing, in that they make CommonJS modules work in browsers. I doubt there is a good reason to be using both in the same project.

# ? Jun 3, 2017 07:25

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

Is anyone out there making a living or any side cash freelancing this sort of work? I'd like to bring in some extra money and I consider myself a pretty solid full stack but mainly front end developer (I do it full time for an agency) but freelance work seems to be Wordpress as far as the eye can see.

# ? Jun 3, 2017 15:04

geeves: Sep 16, 2004

Skandranon posted:

Babel just transpiles. You are not writing JavaScript, you are writing Babel.

Babel is not really its own language, so saying you're writing Babel is misleading.

You are writing JavaScript (and things like JSX for react) that's not yet supported by all browsers. Babel will transpile that JS + JSX to a version of JavaScript that can be used on a wider variety of browsers.

quote:

JavaScript is your ~~bytecode~~ code that you end up with. Same with TypeScript.

TypeScript is a superset of JS and transpiles similarly as Babel to JS. The difference between Babel and TypeScript is that Typescript is more of a language that is strongly typed, so that you know that a field that you declare is the same type. You can write garbage JS in TypeScript, but if you do this, why bother?

code:

function(string: myString) {
  if (true === something) {
    myString = 1; // this will fail
  }    
}

Grunt / Gulp are good for other things as well as part of your build process. It depends how you have your app structured if these come in useful.

# ? Jun 3, 2017 17:33

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

geeves posted:

Babel is not really its own language, so saying you're writing Babel is misleading.

You are writing JavaScript (and things like JSX for react) that's not yet supported by all browsers. Babel will transpile that JS + JSX to a version of JavaScript that can be used on a wider variety of browsers.

While I am not as familiar with Babel as I am with TypeScript... if it needs to be transpiled at all, it's essentially a different language, even if very similar.

# ? Jun 3, 2017 18:26

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

Skandranon posted:

While I am not as familiar with Babel as I am with TypeScript... if it needs to be transpiled at all, it's essentially a different language, even if very similar.

I get what you're saying, but just to be clear Babel's reason for existence is not to create a new language. It lets you use the latest Javascript features before all browsers support them.

So, it turns this:

JavaScript code:

const imAnArrow = (x) => x;

into this:

JavaScript code:

var imAnArrow = function imAnArrow(x) {
  return x;
};

Both of which are valid javascript, its just that the first isn't supported by all browsers.

Thermopyle fucked around with this message at 18:57 on Jun 3, 2017

# ? Jun 3, 2017 18:44

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

prom candy posted:

Is anyone out there making a living or any side cash freelancing this sort of work? I'd like to bring in some extra money and I consider myself a pretty solid full stack but mainly front end developer (I do it full time for an agency) but freelance work seems to be Wordpress as far as the eye can see.

I do. I've got a few clients that are local to me that I approached because I thought their websites were poo poo. Then I've got a couple that contacted me here from the forums based on my elite and amazing posting I guess. All of them I do full-stack stuff for.

It's difficult to get clients though and I'm open to any suggestions for finding more!

edit: oops double post. not the elite and amazing poster I thought I was.

# ? Jun 3, 2017 18:56

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

Sweet thanks for the help.

So I think I just need to look more into Gulp/Grunt and get an idea of what purpose they serve.

# ? Jun 3, 2017 19:41

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

Grump posted:

Sweet thanks for the help.

So I think I just need to look more into Gulp/Grunt and get an idea of what purpose they serve.

FWIW, there's been a movement recently towards not using either of those and just using npm scripts. Webpack plugins plus npm scripts probably cover everything you'd use Gulp or Grunt for.

# ? Jun 3, 2017 19:57

geeves: Sep 16, 2004

Thermopyle posted:

I get what you're saying, but just to be clear Babel's reason for existence is not to create a new language. It lets you use the latest Javascript features before all browsers support them.

So, it turns this:
JavaScript code:
const imAnArrow = (x) => x;
into this:
JavaScript code:
var imAnArrow = function imAnArrow(x) {
  return x;
};
Both of which are valid javascript, its just that the first isn't supported by all browsers.

Skandranon posted:

While I am not as familiar with Babel as I am with TypeScript... if it needs to be transpiled at all, it's essentially a different language, even if very similar.

I AM COMPILING JAVASCRIPT TO JAVASCRIPT WITH BABEL! RAWR!

JavaScript is bytecode :lol:

geeves fucked around with this message at 20:12 on Jun 3, 2017

# ? Jun 3, 2017 20:07

zombienietzsche: Dec 9, 2003

geeves posted:

I AM COMPILING JAVASCRIPT TO JAVASCRIPT WITH BABEL! RAWR!

I mean, you could use Babel for that, but you really should be using js2js.

# ? Jun 4, 2017 04:24

Honest Thief: Jan 11, 2009

meinstein posted:

I mean, you could use Babel for that, but you really should be using js2js.

I like how there were some issues opened on github

# ? Jun 5, 2017 17:32

MrMoo: Sep 14, 2000

Can Winston or Bunyan logging work in a browser with LogStash? I'm surprised how few articles there are on ELK integration with client side logging. Do frameworks hide this or punt it all serverside themselves? Do you batch dump entries over XHR or just use WebSockets for convenience?

# ? Jun 6, 2017 11:46

luchadornado: Oct 7, 2004; A boombox is not a toy!

Everyone used Grunt until Gulp came along, then everyone used Gulp until Webpack got its poo poo together with 2.0 and its documentation and people realized it was far easier to do something in a bash script than using 10 different Gulp plugins maintained by 10 different shitlords. Seeing Grunt and Gulp today are a sign that an org either doesn't like paying down tech debt and/or enjoys self-harm.

Babel used to be an underdog ES6-to-5 transpiler going up against Google's Traceur. Somehow Babel won, and Facebook and the front-end community started turning it into a modular plugin-based build system. Someday soon we'll see job postings for "dedicated Webpack/Babel experts" that only attract masochists that look at front-end toolchains and say "huh, that's not complex enough". Typescript is awesome because its just Javascript with types, ES6 support, and ES7 sprinkled in.

bash + Typescript + webpack and don't look back IMO.

re: transpilation talk, while it's technically correct that Typescript / pre-Babel "JS" are other languages as they go through a process like this: https://github.com/thejameskyle/the-super-tiny-compiler/blob/master/the-super-tiny-compiler.js, I'm not sure that distinction is very useful considering how similar the languages are given that you can take a lot of code written in them and just straight up run it as Javascript in browsers.

Javascript bytecode, if it even exists in a specific browser, is hidden away in the guts of the browser. Transpilers just output valid Javascript - they're not targeting browser bytecode. WebAssembly is a proper bytecode, but in a different ballpark than what we're discussing.

# ? Jun 10, 2017 01:23

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

Helicity posted:

Everyone used Grunt until Gulp came along, then everyone used Gulp until Webpack got its poo poo together with 2.0 and its documentation and people realized it was far easier to do something in a bash script than using 10 different Gulp plugins maintained by 10 different shitlords. Seeing Grunt and Gulp today are a sign that an org either doesn't like paying down tech debt and/or enjoys self-harm.

Babel used to be an underdog ES6-to-5 transpiler going up against Google's Traceur. Somehow Babel won, and Facebook and the front-end community started turning it into a modular plugin-based build system. Someday soon we'll see job postings for "dedicated Webpack/Babel experts" that only attract masochists that look at front-end toolchains and say "huh, that's not complex enough". Typescript is awesome because its just Javascript with types, ES6 support, and ES7 sprinkled in.

bash + Typescript + webpack and don't look back IMO.

re: transpilation talk, while it's technically correct that Typescript / pre-Babel "JS" are other languages as they go through a process like this: https://github.com/thejameskyle/the-super-tiny-compiler/blob/master/the-super-tiny-compiler.js, I'm not sure that distinction is very useful considering how similar the languages are given that you can take a lot of code written in them and just straight up run it as Javascript in browsers.

Javascript bytecode, if it even exists in a specific browser, is hidden away in the guts of the browser. Transpilers just output valid Javascript - they're not targeting browser bytecode. WebAssembly is a proper bytecode, but in a different ballpark than what we're discussing.

I am rarely moved to say this after a post in the Front-end dev thread but:

loving WORD. PREACH.

Typescript/Webpack is so good you will wonder why on earth you EVER bothered with anything else.

# ? Jun 12, 2017 12:28

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

Are there any downsides to TS if you're primarily working with React? I recall hearing something about TS not being able to do functional components until like 2 months after they dropped, but that was a long time ago. Is that kind of lag time still common? Do you ever run into issues with third party libraries or components?

# ? Jun 12, 2017 15:42

luchadornado: Oct 7, 2004; A boombox is not a toy!

prom candy posted:

Are there any downsides to TS if you're primarily working with React? I recall hearing something about TS not being able to do functional components until like 2 months after they dropped, but that was a long time ago. Is that kind of lag time still common? Do you ever run into issues with third party libraries or components?

Typescript doesn't play super well with Immutable.js. You either re-render things like you would with an unoptimized shouldComponentUpdate, create hacky helper functions, or persist the Immutable data structures all the way down into your components. Sometimes your TS models get a little non-intuitive because the object isn't an array, it's an Immutable Map or whatever. Other than that, no. We use TS+Immutable for ~12 web apps and deal with the less-than-optimal parts because what TS gives you is totally worth it. We would give up Immutable before we considered giving up TS - it prevents so many bugs.

# ? Jun 12, 2017 15:59

Kekekela: Oct 28, 2004

We use Flow and I really like it, but could see a switch to TS in my future if it ends up pulling way out in front in terms of tooling or support. Right now I feel like TS has the slight edge there, but not enough to make me pull the trigger on a switch.

# ? Jun 12, 2017 16:37

Adbot: ADBOT LOVES YOU

# ? May 22, 2024 22:13

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

I've been on a TypeScript project for a few weeks now.

It's ok. Nothing mind blowing for me, though.

# ? Jun 12, 2017 16:40

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

«‹›235 »