|
Grump posted:here it is user ljkrebs approves
|
# ? May 16, 2017 22:36 |
|
|
# ? Jun 15, 2024 23:04 |
|
Grump posted:here it is Viewing on mobile, your sign in modal is off center and cut off on the right.
|
# ? May 16, 2017 23:05 |
Grump posted:here it is Congrats! The phone number format restriction might not work so well for international phone numbers
|
|
# ? May 16, 2017 23:18 |
|
Grump posted:here it is Get a HTTPS cert from Let's Encrypt. They're free.
|
# ? May 16, 2017 23:20 |
|
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 Also got to add some margins in some places and make the submit buttons have the same styling on mobile fletcher posted:Congrats! 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 |
|
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:
|
# ? May 17, 2017 17:20 |
|
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 |
|
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. 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 |
|
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 |
|
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:
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:
Newf fucked around with this message at 23:41 on May 28, 2017 |
# ? May 28, 2017 23:32 |
|
You can also do this:JavaScript code:
If you omit the curly braces the return statement is implied.
|
# ? May 29, 2017 00:14 |
|
Dogcow posted:You can also do this: sonofa... Thanks
|
# ? May 29, 2017 01:17 |
|
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 |
|
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 |
|
HaB posted:K got another "general opinion" sort of question. 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 |
|
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. 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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
HaB posted:K got another "general opinion" sort of question. 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 |
|
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 |
|
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 |
|
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 |
|
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 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:
|
# ? Jun 3, 2017 17:33 |
|
geeves posted:Babel is not really its own language, so saying you're writing Babel is misleading. 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 |
|
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:
JavaScript code:
Thermopyle fucked around with this message at 18:57 on Jun 3, 2017 |
# ? Jun 3, 2017 18:44 |
|
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 |
|
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 |
|
Grump posted:Sweet thanks for the help. 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 |
|
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. 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 geeves fucked around with this message at 20:12 on Jun 3, 2017 |
# ? Jun 3, 2017 20:07 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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. 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 |
|
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 |
|
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 |
|
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 |
|
|
# ? Jun 15, 2024 23:04 |
|
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 |