|
Ape Fist posted:TS is such a vastly superior iteration of JS that it's mental. TS would be a lot better if it went back in time and still supported generation of IIFE. Currently the best it can do with current versions is compiling a bunch of ES5 files with ES6 imports which is You still need rollup (my fav) or Webpack (god forbid) or etc to make it work. It used to work on its own which was awesome.
|
# ? Mar 15, 2018 05:07 |
|
|
# ? Jun 8, 2024 17:50 |
|
Nolgthorn posted:TS would be a lot better if it went back in time and still supported generation of IIFE. Currently the best it can do with current versions is compiling a bunch of ES5 files with ES6 imports which is You still need rollup (my fav) or Webpack (god forbid) or etc to make it work. You CAN still use IIFE if you want, but be prepared to do all your own custom bundling. It's Webpack/Rollup that need ES6 imports.
|
# ? Mar 15, 2018 05:40 |
|
Just learned about Fusebox. Any thoughts? Is it easier/less prone to breaking than Webpack?
|
# ? Mar 15, 2018 17:22 |
|
I have a question about testing promises in Angular with Jasmine. Is this the thread for that? edit: basically I don't understand how to test a promise or wtf I'm doing. I'm still relatively new to all this. double edit: i figured out how to write my specific spec for this promise but I'm still not really sure how to test promises in general lol AlphaKeny1 fucked around with this message at 22:40 on Mar 15, 2018 |
# ? Mar 15, 2018 22:16 |
|
My understanding of this new context API for React is that I no longer need to do Redux/Flux and can use context as a substitute for the Store. Am I misreading this?
|
# ? Mar 16, 2018 15:27 |
|
/me checks to see if parsing JSON in Elm still kind of sucks.... Well then, On a scale of 1-10 how much of a pain is it to use TypeScript the first time? Going to be doing a new "smallish" React project for myself, so going a little slow while dealing with it isn't a big deal, but I want to actually enjoy working on this thing. Any "essential" guides or references you folks who use it regularly can recommend?
|
# ? Mar 16, 2018 15:35 |
|
Love Stole the Day posted:My understanding of this new context API for React is that I no longer need to do Redux/Flux and can use context as a substitute for the Store. Am I misreading this? Depends on your requirements. Having access to the context doesn't mean you're getting unidirectional data flow like you would with flux/redux patterns. The pattern itself is quite useful for making sense of data changes from all over the place in large apps, and redux pretty much forces you to be a little more strict and explicit about it.
|
# ? Mar 16, 2018 15:43 |
|
Lumpy posted:/me checks to see if parsing JSON in Elm still kind of sucks.... TS is easier when you're starting a project from scratch than when you're converting an existing project. How hard it is going to be kind of depends on how familiar you are with C#/Java style languages. I don't think it's going to be too difficult for you, so maybe a 4 out of 10 difficulty rating. I can't really remember what I used to learn TS from scratch, but I feel like I used the official docs a lot and then just googled specific questions I had.
|
# ? Mar 16, 2018 15:48 |
|
Love Stole the Day posted:My understanding of this new context API for React is that I no longer need to do Redux/Flux and can use context as a substitute for the Store. Am I misreading this? It can be used as a wholesale replacement, yes. You'll have to figure out your own way of passing around actions and so on, but if you were to keep the entire app's state as the state of the top-level component, and all actions were methods on said component, you can get "redux-like" behavior using only the new Context API. The new stuff actually operates almost exactly like Redux, in a lot of ways. I wonder if FB hiring Dan Abramov had something to do with that.... :ponder: I might play with new Context stuff in my new project (see above post!)... not sure how best to handle large state trees and async actions etc. but should be pretty easy to get a handle on, maybe. Dealing with multiple contexts looks like a pain, but I've only read a little on it, so I'm not sure if you'd even want to do multiple contexts.
|
# ? Mar 16, 2018 15:57 |
Thermopyle posted:TS is easier when you're starting a project from scratch than when you're converting an existing project. I agree with all of this. I did have a harder time but I think it was because I was trying to deal with the Angular 2 beta and trying to grok RxJS at the same time. That learning curve was a wall until it suddenly it all clicked. Now I wish I could use TS for everything.
|
|
# ? Mar 16, 2018 16:55 |
|
Yeah Angular 2 offers a good TS experience and also helps you to learn Angular 2.
|
# ? Mar 17, 2018 13:09 |
|
Everyone looking to replace Redux seems to forget about the main benefit: the developer experience is top notch
|
# ? Mar 17, 2018 21:48 |
|
I switched to Apollo Client + GraphQL to handle state in a personal project because I felt like there was always far too many steps involved with managing state with Redux, especially when it came to really simple state changes. Definitely a real steep learning curve but now I really can't see myself using anything else. You query for data with something like: code:
It is a thoroughly nice experience.
|
# ? Mar 17, 2018 23:37 |
|
prom candy posted:Everyone looking to replace Redux seems to forget about the main benefit: the developer experience is top notch By that you mean the experience of developers using it? I've had a breeze using vuex, which uses mutable state, you mute it, it knows you muted it, simple as that. Feels like redux is a lot of boilerplate for ideological reasons.
|
# ? Mar 18, 2018 00:19 |
|
I mean specifically the dev tools. Being able to do time travel, see the whole state tree, re-dispatch actions, etc. I am definitely interested in checking out react-apollo, but it uses Redux under the hood doesn't it?
|
# ? Mar 18, 2018 06:36 |
|
Yes, the redux dev tools are super great and it's difficult to use anything else now.
|
# ? Mar 18, 2018 06:43 |
|
I've got two divs, each 100vw, one representing a grid of projects and another a single project.code:
|
# ? Mar 18, 2018 06:52 |
|
prom candy posted:I mean specifically the dev tools. Being able to do time travel, see the whole state tree, re-dispatch actions, etc. I am definitely interested in checking out react-apollo, but it uses Redux under the hood doesn't it? Apollo Client recently moved into 2.0, which uses its own system rather than Redux. I do have to concede that the Redux dev tools are absolutely top notch, though. AC Dev Tools are incredibly immature by comparison. I deeply miss the ability to see how the state tree evolved over time, but I've gotten by without it.
|
# ? Mar 18, 2018 09:02 |
|
huhu posted:I've got two divs, each 100vw, one representing a grid of projects and another a single project. Could you set the grid to 100vh and overflow auto so that you're scrolling the div and not the body?
|
# ? Mar 18, 2018 16:53 |
|
prom candy posted:Everyone looking to replace Redux seems to forget about the main benefit: the developer experience is top notch I love redux dev tools, which is worth staying with Redux for a while regardless, but having to reinvent parts of Redux to replace it has me mostly going "Hmm, why don't I just keep using Redux?" I think the endgame will be a Redux-like thing that creates contexts, and then some sort of context composer so you have reducers for parts of your state tree like Redux does now. So I would expect to see React get something like Redux's store / combineReducers in the near future as sort of a canonical Flux architecture. Or maybe not! As for Redux boilerplate... do you people not have macros / scripting in your IDEs??
|
# ? Mar 18, 2018 20:00 |
|
huhu posted:I've got two divs, each 100vw, one representing a grid of projects and another a single project. Do this: prom candy posted:Could you set the grid to 100vh and overflow auto so that you're scrolling the div and not the body?
|
# ? Mar 18, 2018 20:01 |
You haven't seen boilerplate until you have used ngrx. All the redux boilerplate + types + RxJS.
|
|
# ? Mar 18, 2018 20:09 |
|
gmq posted:You haven't seen boilerplate until you have used ngrx. All the redux boilerplate + types + RxJS. It's true, but this package has helped me reduce the boilerplate in my angular/rxjs/redux project: https://github.com/cartant/ts-action. I'm using angular-redux instead of ngrx, but I believe it works with both.
|
# ? Mar 19, 2018 11:12 |
|
AlphaKeny1 posted:I have a question about testing promises in Angular with Jasmine. Testing code that generates promises or receives them? Generates them: add a then block after your call that tests your conditions and then calls the done function. Received them: use a spy to return a new promise, which you can then test in unresolved, resolved, or error state. Alternate answer: you should be using Observables not Promises in Angular.
|
# ? Mar 19, 2018 12:47 |
LOOK I AM A TURTLE posted:It's true, but this package has helped me reduce the boilerplate in my angular/rxjs/redux project: https://github.com/cartant/ts-action. I'm using angular-redux instead of ngrx, but I believe it works with both. that looks so much better
|
|
# ? Mar 19, 2018 13:31 |
|
gmq posted:that looks so much better If it's at all possible I would really recommend switching any code that uses Redux with TS to that library, or something similar. My own Redux code went through three or four iterations before I settled on ts-action. Each of those iterations probably cost me about 10 hours of tedious rewriting, but in the end it was worth it. And the nice thing about Redux is that none of the other code in the app was affected much. Here's an example of a rewritten actions file: https://gist.github.com/magnusbakken/2380b0384b725113f5e14a9eefb5a5d4
|
# ? Mar 19, 2018 14:28 |
|
Whoa this looks really nice, my redux ducks are way too big in my React/Redux/TS project. I noticed you're importing your other interfaces from <redacted>, where do you actually keep your model interfaces? I've been colocating them with my other Redux stuff but that hasn't really scaled well. Was thinking about creating a types folder that contained each interface in its own file and exported all of them from an index.ts file. I'm a little worried about the potential for circular dependencies but it would be nice to do "import { Author, Book, Library } from 'types'" or something like that.
|
# ? Mar 19, 2018 14:35 |
|
prom candy posted:Whoa this looks really nice, my redux ducks are way too big in my React/Redux/TS project. I'll briefly explain our overall approach. I'd love to hear other people's experiences with Angular and Redux, since it isn't as widespread a combo as React/Redux. For us, each module has the following structure: pre:store/ - actions.ts - epics.ts - reducer.ts - service.ts - state.ts Most of the time we just toss data from the server directly into the store, which is possible because the API was very much written with our own client in mind. In cases where we need to transform the data we put extra definitions in the state.ts file and do the conversion in the reducer. The rest of the time the only thing in state.ts is an interface that defines the reducer state for the module. It would probably be fine to join reducer.ts and state.ts together as one file. Components never interact directly with the store. Actions are dispatched from the service, and store changes are also relayed through the service class. The service.ts for the module from the gist looks like this: code:
The actual API calls happen in epics.ts. For example, when a LoadArticleAction happens it triggers an epic, which starts an API call and returns either LoadArticleSucceededAction or LoadArticleFailedAction. That looks basically like this (slightly simplified): code:
We've had to make most of this up as we go, so I wouldn't necessarily recommend all of it to others. It's still a lot of work to do things that could be done with much less ceremony, but hopefully the benefits of Redux will shine through. (Our app is not in production yet.)
|
# ? Mar 19, 2018 15:16 |
|
Hey dudes. Do I still need Webpack to make Typescript support imports? When I last checked (a year ago), you could use TSC alone for single-file projects, but multi-file projects required using Webpack, awesome-typescript-loader, sourcemap-loader, webpack config files etc. Search results on the subject are mainly from 2016-2017.
|
# ? Mar 19, 2018 15:45 |
|
I'm trying to get an ember 1.x app that I built 3 years ago working locally and holy poo poo what a nightmare. Nothing is compatible with anything. The version of ember-cli doesn't seem to work with versions of node past 0.x, I can't use yarn, the whole thing predates the idea of automatic version locking, and this was my first modern JS application so nothing makes any god drat sense! I almost want to just tell the client that the app is now a delicately preserved artifact and disturbing it ever so slightly could bring the whole thing down. They declined any long-term support or updates so it's just been sitting.
|
# ? Mar 19, 2018 20:04 |
|
prom candy posted:I'm trying to get an ember 1.x app that I built 3 years ago working locally and holy poo poo what a nightmare. Nothing is compatible with anything. The version of ember-cli doesn't seem to work with versions of node past 0.x, I can't use yarn, the whole thing predates the idea of automatic version locking, and this was my first modern JS application so nothing makes any god drat sense! I almost want to just tell the client that the app is now a delicately preserved artifact and disturbing it ever so slightly could bring the whole thing down. They declined any long-term support or updates so it's just been sitting. prom candy posted:They declined any long-term support or updates so it's just been sitting. Problem solved!
|
# ? Mar 19, 2018 20:09 |
|
Now they're back and want stuff and have money I'm actually leaving this job in a couple weeks but I need to get it into a place so that my co-workers can use it. I've thought about just trying to get it running on Ember 2.x but people are saying that's a bit of an arduous task.
|
# ? Mar 19, 2018 20:17 |
|
I've been playing whack-a-mole for 4 hours now with Webpack/React/Express and I could use some help. I am trying to get dev to run with npm start and prod to run with an express server. I've included my issue first and then the relevant code below. Would really appreciate any help. Running this: code:
code:
code:
Finally, do I need index.ejs at all? Express seems to want it but I don't think it's necessary? File Structure code:
code:
code:
code:
code:
code:
|
# ? Mar 19, 2018 21:17 |
|
prom candy posted:I'm trying to get an ember 1.x app that I built 3 years ago working locally and holy poo poo what a nightmare. Nothing is compatible with anything. The version of ember-cli doesn't seem to work with versions of node past 0.x, I can't use yarn, the whole thing predates the idea of automatic version locking, and this was my first modern JS application so nothing makes any god drat sense! I almost want to just tell the client that the app is now a delicately preserved artifact and disturbing it ever so slightly could bring the whole thing down. They declined any long-term support or updates so it's just been sitting. 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.
|
# ? Mar 20, 2018 00:52 |
|
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?
|
# ? Mar 20, 2018 02:16 |
|
Still banging away at various issues. Have perhaps, some more directed questions with regards to React/Express. Here's my server.js: code:
|
# ? Mar 20, 2018 02:41 |
|
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? 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).
|
# ? Mar 20, 2018 03:03 |
|
huhu posted:Still banging away at various issues. Have perhaps, some more directed questions with regards to React/Express. not mine, but do something like this: https://gist.github.com/ryanoglesby08/1e1f49d87ae8ab2cabf45623fc36a7fe
|
# ? Mar 20, 2018 03:28 |
|
I deployed a node/express/ejs app on my DigitalOcean Ubuntu droplet today and it required a bunch of stuff like configuring an nginx reverse proxy, which drove me insane (wouldn't serve static css or js) until I discovered the problem was a \ instead of /. Derp. Anyone used the preconfigured node setup DO offers? Does it alleviate the annoyance of having to mess with nginx? I'm thinking it would be wise to get another droplet just for node.
|
# ? Mar 20, 2018 04:02 |
|
|
# ? Jun 8, 2024 17:50 |
|
Lumpy posted:not mine, but do something like this: Ugh, what am I missing? I copied what they had: code:
code:
code:
code:
Edit: huhu.com requests the static from huhu.com/static huhu.com/bar requests the static from huhu.com/static huhu.com/bar/buzz requests the static from huhu.com/buzz/static Still not sure why /buzz is getting included. huhu fucked around with this message at 04:48 on Mar 20, 2018 |
# ? Mar 20, 2018 04:25 |