|
smackfu posted:Anyone have tips on working with static assets (like images) and CDNs and file naming? We recently had a designer say “oh that SVG we gave you that you deployed into production had a small layering bug, here is the new one.” We could just add a “b” or “v2” to the filename but maybe we should version them from the start? It’s our first time dealing with the CDN for this stuff so we are kind of winging it. From my own experience, we kept the files named the same, overwrote them on the storage, and then ran an invalidation on AWS Cloudfront for that specific file path. But that was also winging it.
|
#
?
Mar 11, 2019 15:42
|
|
|
|
| # ? Apr 28, 2024 06:57 |
|
|
Either strategy is valid. I like versioning filename just because it avoids the complexity, and is ok for long-lived assets. I suggest a proper versioning instead of "..._new"  For short-lived, iterated-over assets, cache invalidation is probably a better option.
|
|
#
?
Mar 11, 2019 16:02
|
|
|
I get that you might no want to put a library like d3 on your project, but why output an entirely new svg instead of leveraging CSS, especially for the use case given?
|
|
#
?
Mar 11, 2019 16:08
|
|
|
smackfu posted:Anyone have tips on working with static assets (like images) and CDNs and files Webpack renames our images with hashes of their content.
|
|
#
?
Mar 11, 2019 17:45
|
|
|
gbut posted:Either strategy is valid. I like versioning filename just because it avoids the complexity, and is ok for long-lived assets. I suggest a proper versioning instead of "..._new" This is correct. The right way to version an asset is with "_FINAL". The next version becomes "_FINAL2". The version after that is "_FINAL2_corrected", etc.
|
|
#
?
Mar 11, 2019 18:56
|
|
|
bartkusa posted:Webpack renames our images with hashes of their content. This is correct and a major advantage to using modern build tooling like Webpack. It also lets you start to use aggressive cache-control headers on your static assets.
|
|
#
?
Mar 11, 2019 19:31
|
|
|
Yeah the serious answer is to use Webpack. If you're not currently using it, be aware that since version 4 it (apparently) became a lot easier to use and integrate into your build/deploy process.
|
|
#
?
Mar 11, 2019 20:07
|
|
|
Third-ing this. ^
|
|
#
?
Mar 11, 2019 20:36
|
|
|
Can't wait for Angular 8.0 to drop so I can re-learn the RXJS syntax again like we have to do every loving version.
|
|
#
?
Mar 12, 2019 20:57
|
|
|
So we started using Vue for the employee-facing parts, as opposed to Angular for the customer-facing parts. In Angular we've used this to structure the "pages" of the site to different projects, which each can have sharable code and can be built independently of each other as well as, ultimately, built as one big app. Is there an equivalent for Vue? I keep looking around and since I'm not getting any results I feel I'm either overthinking it, or it's a dumb idea. Basically I'd like it where the different 'pages' of our employee-facing parts can be built independently, and optionally as one large one if we ever want to do a big SPA. code:EDIT: Also, using the Vue CLI
|
|
#
?
Mar 12, 2019 21:09
|
|
|
Those look just like different entry points that use the same shared components. You could have an entry point for page1, page1,... and one that incorporates those elements in the main app.js. similar with router and state: split into modules, and instantiate in a very simple way, attach modules, and you can do that for individual pages as well as the main app. Not sure if I'm missing something.
|
|
#
?
Mar 12, 2019 22:41
|
|
|
Volguus posted:On the other hand, you have this simple page application, with a form with 5 fields on it that submits some information to the backend to be saved into the database, and there are people out there who use angular or react or god knows what other 3mb minified abomination only because they do not know that document.getElementById is a thing. react + react-dom is like 100 kb these days, it's fine to use a front end library for simple interactions or widgets if you want to. yeah you shouldn't run a fancy library for a simple form but blanket statements and strawmen are meaningless. if you wanna get real spooked try loading a webapp that was created in Wix Code or some other wysiwig nightmare and watch as it somehow transfers like 30mb of javascript (something I encountered recently for real), it's like the Dreamweaver of yore but for applications!
|
|
#
?
Mar 13, 2019 03:02
|
|
|
Is there any way to serve a non 200 status in a react app without using a server? A library we use looks for json files of translations and fallbacks to English if it doesn't get a 200. Problem is that react juat gives it a 200 you must enable javascript response thus crashing the lib later. This is looking for the files in the public folder.
|
|
#
?
Mar 13, 2019 19:12
|
|
|
What's your actual web server here? A client-side React app isn't really "serving" anything and can't return HTTP statuses. Are you referring to webpack-dev-server with create react app?
|
|
#
?
Mar 13, 2019 23:03
|
|
|
useReducer and useContext are becoming my favorite thing in React. the only problem is trying to control components rerendering all the time when you don't want them to, which has not proved to be a big problem yet but certainly will at scale. anyone have suggested resources for learning about this kind of thing? should I be looking at memoizing components?
|
|
#
?
Mar 14, 2019 20:21
|
|
|
I think the official party line is "Concurrent React is coming, which will solve all problems forever." I think the other thing to keep in mind is that re-renders are pretty cheap if they don't do any calculation. What's causing all your extra rendering now anyway? Just more reliance on the Context API and components re-rendering because part of the context that you don't actually care about gets updated?
|
|
#
?
Mar 14, 2019 21:17
|
|
|
my bony fealty posted:useReducer and useContext are becoming my favorite thing in React. the only problem is trying to control components rerendering all the time when you don't want them to, which has not proved to be a big problem yet but certainly will at scale. anyone have suggested resources for learning about this kind of thing? should I be looking at memoizing components? YMMV, your usecase/setup might be completely different and it might work fine, so go ahead and just try stuff, but: I'm gonna guess at somewhere you have a collection of stuff: that's going to be your issue. Memo ain't any use (directly) for that (isn't really much use for context stuff), and you're going to have to do some very funky stuff to get it working optimally. I rebuilt one of the smaller apps at my work, replacing redux with context. Pretty simple, normalised model, was very careful about what parts I wanted to update, split across multiple providers, still getting unwanted re-renders all over the place. Rerenders are pretty cheap, so not a massive issue, but couldn't optimise them away, went back to redux. Context is really good for stuff where you have a few states known in advance (eg theme switching, auth). Context is really not so good for stuff like collections, and isn't currently designed to be. There is a second argument you can give to createContext (unstable_observedBits) that allows you to do optimisations via bit flags, so they're clearly thinking about how to fix stuff. react-redux hit this issue (among others) when they switched to using context, and they're ripping context out ATM and reverting back to how it worked before
|
|
#
?
Mar 14, 2019 21:44
|
|
|
prom candy posted:What's your actual web server here? A client-side React app isn't really "serving" anything and can't return HTTP statuses. Are you referring to webpack-dev-server with create react app? We are working with a bank which has a like 3 week onboarding to get to their jira through citrix so I am assuming we can't change their server environments. My project manager thinks we can solve thid by ejecting and removing webpack but am I assuming right when I think we would need to conf their server to fix it?
|
|
#
?
Mar 14, 2019 22:22
|
|
|
Sistergodiva posted:We are working with a bank which has a like 3 week onboarding to get to their jira through citrix so I am assuming we can't change their server environments. It's still kinda unclear what you're wanting. React doesn't have anything to do with HTTP status codes. It doesn't even know networking of any type exists.
|
|
#
?
Mar 14, 2019 23:13
|
|
|
Your boss may be confused over whatever local dev server your React install of choice is using to serve the pages locally (hence their mention of webpack? Version 3 of that had a server which Angular still uses iirc). Once you build the app, it's just static content with no self-serving capability. You won't be able to do anything with HTTP statuses beyond responding to them without the server to barf them out.
|
|
#
?
Mar 15, 2019 03:38
|
|
|
Sistergodiva posted:We are working with a bank which has a like 3 week onboarding to get to their jira through citrix so I am assuming we can't change their server environments. It sounds like you're confusing React with something like Node & Express. Like others have said, React is not a web server that handles requests and provides responses. It's literally just HTML and Javascript that runs in the browser.
|
|
#
?
Mar 15, 2019 04:29
|
|
RobertKerans posted:Context is really good for stuff where you have a few states known in advance (eg theme switching, auth). Context is really not so good for stuff like collections, and isn't currently designed to be. There is a second argument you can give to createContext (unstable_observedBits) that allows you to do optimisations via bit flags, so they're clearly thinking about how to fix stuff. react-redux hit this issue (among others) when they switched to using context, and they're ripping context out ATM and reverting back to how it worked before What's the problem, specifically? I am using Context to pass down my shared state, including a bunch of lists, and I haven't noticed any issues. Is it just a performance thing?
|
|
|
#
?
Mar 15, 2019 10:13
|
|
|
SimonChris posted:What's the problem, specifically? I am using Context to pass down my shared state, including a bunch of lists, and I haven't noticed any issues. Is it just a performance thing? Yeah; just for context (heh) I am making a direct comparison with redux, as in replacing that with Context, and I ran into perf problems pretty quickly. The issue was the diffing of the state object, and the fact that Context is completely dumb. Any change to that object triggers rerenders to all subscribed consumers in the state tree. Memo doesn't help at all because it uses shallow comparison. I found I was basically trying to duplicate what react-redux already does better (use a fairly complex battery of methods to decide which parts of the state have to update) and having to write sometimes quite complex logic in components to prevent them rerendering unecessarily. It's all contextual, and I hope over this year they work on improving it because I would love to be able to strip out redux. The DX is great; in the app I rebuilt, I got it down to 4 dependencies (react, react-dom, then the app-specific aws-amplify, and history for basic routing), hacked out a few thousand lines of code, and the code I rewrote was much simpler (until the diffing logic started to get gnarly). I'd really like to be back in that position, if only from a maintenance pov, and if the performance thing isn't an issue I'd totally recommend it. RobertKerans fucked around with this message at 14:44 on Mar 15, 2019 |
|
#
?
Mar 15, 2019 14:26
|
|
RobertKerans posted:Yeah; just for context (heh) I am making a direct comparison with redux, as in replacing that with Context, and I ran into perf problems pretty quickly. The issue was the diffing of the state object, and the fact that Context is completely dumb. Any change to that object triggers rerenders to all subscribed consumers in the state tree. Memo doesn't help at all because it uses shallow comparison. I found I was basically trying to duplicate what react-redux already does better (use a fairly complex battery of methods to decide which parts of the state have to update) and having to write sometimes quite complex logic in components to prevent them rerendering unecessarily. I understand. I get around such performance issues by having Container components, which extract the needed state from the context and feeds it to view components, which only rerender when their props change. The only diffing logic needed is to make the views PureComponents.
|
|
|
#
?
Mar 15, 2019 17:00
|
|
|
SimonChris posted:I understand. I get around such performance issues by having Container components, which extract the needed state from the context and feeds it to view components, which only rerender when their props change. The only diffing logic needed is to make the views PureComponents. can you post an example of how you do it, is it just copying the context into new state to pass down? any issues with objects and having to make deep copies to avoid accidentally mutating the original context state? or are you saying the container grabs from context and prop drills it directly down to view, no copying? do y'all use anything you like for route transition animations in React? I'm using Popmotion Pose right now (with Reach Router) and while it works pretty well for simple routing I am running into issues with nested routes, there doesn't seem to be a good way to tell it not the call the top-level router animation when a nested route (which is currently not animated) change happens. the route change will happen right away (in the nested router) and then the top-level animation will play, to the appearance of the component animating into itself. for now I've sorta fixed it by telling it to render a non-animated router when activating a nested transition, but this does not seem like a good solution. I'm looking for something that can do left/right slide route transitions, nothing fancy, that ideally can handle animations for nested routers that are inside of another animated router. I wanna have lil widgets that are controlled by a nested router sliding around.
|
|
#
?
Mar 15, 2019 20:48
|
|
|
I've got typescript code which uses the 'name' property on an array of types at runtime. This has worked fine in development mode (vue-cli), but in build mode it seems like some optimization is clobbering the class names in transpilation, and each type has name 't'. Any webpack folks have a suggestion for a config flag that will avoid this optimization? e: Here I go. code:Newf fucked around with this message at 07:36 on Mar 16, 2019 |
|
#
?
Mar 16, 2019 07:22
|
|
my bony fealty posted:can you post an example of how you do it, is it just copying the context into new state to pass down? any issues with objects and having to make deep copies to avoid accidentally mutating the original context state? or are you saying the container grabs from context and prop drills it directly down to view, no copying? code:
|
|
|
#
?
Mar 16, 2019 11:03
|
|
|
That's a good solution but it's basically also just react-redux. I guess if you want to avoid dealing with the rest of Redux it makes sense. You could probably write your own HoC or render prop component that takes a mapStateToProps function and save yourself writing all those container components actually!
|
|
#
?
Mar 16, 2019 19:10
|
|
|
First time using redux and react-redux and I'm confused. A story in three reducers...code:code:code:
|
|
#
?
Mar 18, 2019 14:44
|
|
|
I'm pretty new at all of this and am still learning. I have 8 hours at work everyday to listen to podcasts and was wondering if there are any that one of you can recommend to me for a beginner. Just to help supplement what I'm learning on my own/through this bootcamp. Maybe ways of thinking, or algorithms, or ways to code cleanly. I'm not sure exactly what I'm even looking for is part of the problem.
|
|
#
?
Mar 18, 2019 15:09
|
|
|
dupersaurus posted:First time using redux and react-redux and I'm confused. A story in three reducers... In the first two you’re updating the state object directly. React-redux expects a new state object if the state has changed, which is what happens in the third example. The first example can be rewritten as: code:
|
|
#
?
Mar 18, 2019 15:37
|
|
justizor posted:In the first two you’re updating the state object directly. React-redux expects a new state object if the state has changed, which is what happens in the third example. code:
|
|
|
#
?
Mar 18, 2019 15:41
|
|
|
justizor posted:In the first two you’re updating the state object directly. React-redux expects a new state object if the state has changed, which is what happens in the third example. Ahhhh that's it, doc reading fail. I thought Object.assign (and probably _.extend as well) was returning a new object, not mutating the first param. Thanks!
|
|
#
?
Mar 18, 2019 15:50
|
|
|
dupersaurus posted:Ahhhh that's it, doc reading fail. I thought Object.assign (and probably _.extend as well) was returning a new object, not mutating the first param. Thanks! It returns the first param and mutates it! I don't like this, myself, I consider it hazardous for exactly the reason you've just experienced. I have a similar issue with Array.prototype.sort, which sorts the input array in place but also returns the input array, behaviour which is shockingly easily mistaken for "returns a brand new, sorted array, leaving the original untouched". When I write a function which mutates one of its parameters I generally make it so that the function returns undefined. And then I put a honking great comment warning about which parameter gets mutated in place...
|
|
#
?
Mar 18, 2019 16:45
|
|
|
RC Cola posted:I'm pretty new at all of this and am still learning. I have 8 hours at work everyday to listen to podcasts and was wondering if there are any that one of you can recommend to me for a beginner. Just to help supplement what I'm learning on my own/through this bootcamp. Maybe ways of thinking, or algorithms, or ways to code cleanly. I'm not sure exactly what I'm even looking for is part of the problem. Hey I was in this exact situation a couple years ago. I've never really found anything good for learning algorithms, but as far as software in general goes: https://completedeveloperpodcast.com/ Haven't listened to this in a while but earlier episodes track one of the hosts through from knowing barely anything about code to landing a job within a couple years, lots of good content. https://frontendhappyhour.com/ Show with a changing panel of guests talking about modern front-end development http://bikeshed.fm/ weekly show usually about software development in general episodes focusing on a specific practice or technology with guests https://nodogmapodcast.bryanhogan.net/ Interview show, Favors technology around Windows development, but some general stuff as well https://www.thisagilelife.com/ was very helpful around learning all of the bullshit agile terminology and practices.
|
|
#
?
Mar 18, 2019 17:07
|
|
|
For webdev and frontend stuff, I really like Syntax.fm It's a couple of independent developers, that run their business on making training courses for people. They talk about all kinds of stuff, from the small things to entire frameworks. https://www.google.com/podcasts?feed=aHR0cHM6Ly9mZWVkLnN5bnRheC5mbS9yc3M_X19zPW9jZXh5Ym40M3NhY3dvbWMybzho
|
|
#
?
Mar 18, 2019 18:21
|
|
|
I believe there was a website mentioned several times here that gives you structured learning in front end from 0 to hero. Anyone know what I'm talking about?
|
|
#
?
Mar 18, 2019 23:59
|
|
|
https://www.freecodecamp.com ? There are a few, but that is the one I recommend whenever someone asks.
|
|
#
?
Mar 19, 2019 00:04
|
|
|
Is anyone here developing on Windows? If yes, what's the best way to have a modern web development environment?
|
|
#
?
Mar 19, 2019 00:36
|
|
|
|
| # ? Apr 28, 2024 06:57 |
|
|
Just working on switching over from MacOS right now actually. WSL (Windows Subsystem for Linux) is working pretty well. Still getting used to a lot of things and not 100% sold on a terminal emulator yet, but I have my whole stack running. For my back-end services I'm using Docker, and I did have to upgrade to Windows 10 Pro in order to use Docker for Windows, otherwise you have to gently caress around with docker-machine and setting up your own VMs which I was willing to pay $100 not to do. Windows definitely isn't the poo poo show it used to be now that there's WSL, although you still have to do some finagling to get things working the way you want.
|
|
#
?
Mar 19, 2019 00:43
|
|