|
Pollyanna posted:
No offense, but I've seen a few posts from you recently that seem to have a similar theme. You're learning how to program (I think) and you see cool poo poo that you want to try, but you haven't done the basics so you don't understand what the cool poo poo is actually trying to fix. If I'm right I'd recommend just sticking to raw html, javascript and whatever server language you know for and just get something done. I'm not trying to make you feel bad but you obviously don't understand the "why" behind a lot of the stuff you're talking about.
|
#
¿
Dec 4, 2013 20:31
|
|
Whoops I got that wrong then. What I was thinking of was some sort of tool that's basically a text field, then a list of text fields with an associated integer, then a table of variable rows, then a radio button or something. Would it make sense to try and MVC that or is that better done through plain HTML?
|
|
| # ¿ May 2, 2024 10:05 |
|
|
If it works it works, but one of the issues is that a lot of these frameworks add a little bit of complexity in order to do something that's beneficial in a production environment, but if you're just building simple examples you don't need to worry about MVC or writing clean code or whatever, you just hack away at a small problem until you start to get it. It makes more sense if you're building something to keep on using but if you're just learning then hack away at it.
|
|
#
¿
Dec 4, 2013 20:54
|
|
|
Pseudo-God posted:I want to do it without a server-side script at all, but I guess the tech is not here yet. To clarify, the tech will never be here because what you are talking about is fundamentally a bad idea. The problem is generally solved by wrapping the database in an API of some kind and then having the client query against the API. The goal is to never allow the client to say "I want to run SQL", you let them say "I want data" or "I want to write data" instead.
|
|
#
¿
Dec 11, 2013 14:14
|
|
|
Yeah, it's probably best to start with a real TDD book if you're interested in unit testing. Unit testing is a little all or nothing, where trying to tack tests onto code that wasn't written for it can be painful and the tests tend to be brittle. Integration testing is a little less all or nothing, in that it's easy to write a test for the happy path that demonstrates that the core system works.
|
|
#
¿
Dec 20, 2013 03:35
|
|
|
an skeleton posted:Got a question. I'm an intern at a local company and one of our goals this month is to get jasmine/karma testing online for one of our company's web applications this month. Problem is, the people who are supposed to help us are always busy and it doesn't seem like its gonna get done unless we do it ourselves. However I have no experience with unit testing and I'm feeling kinda intimidated by the whole idea, does anyone have any guidance for getting a jasmine/karma testing framework online for a large angular/jquery web app? It depends on what you're actually trying to do but 100% test coverage in a month for a large project is going to be unreasonable. The easiest thing to do would probably be to define some critical paths and try to get tests up for those. Testing after the fact is also generally a bad idea.
|
|
#
¿
Mar 10, 2014 03:34
|
|
|
Kobayashi posted:It's been a while since I've used Bower, but does it behave consistently? Last time I tried it, some packages would put their stuff in subdirectories, some wouldn't. Some would include non-JS assets, some wouldn't. Some would include version numbers, some wouldn't. In the end I'd still have to go through and figure out how the package named itself so I didn't see the value. Maybe I'm not using it properly or things have changed, though... IIRC it's literally a git wrapper. It just goes to the git repository for the project, finds the right tag, excludes a bunch of files that somebody specified and downloads the rest.
|
|
#
¿
Jun 21, 2014 16:56
|
|
|
Pollyanna posted:Aha, that's done it. Thanks I don't necessarily have anything against this but as far as I know this isn't really the recommended way of looking at it. Have you looked at Flux at all?
|
|
#
¿
Dec 8, 2014 23:21
|
|
|
Thermopyle posted:One of the problems with this is that you have to think about your props too much and you end up with this massive house of cards where you've got to make sure you're passing just the right prop to just the right component. To be fair, IIRC that's what Flux recommends. You use the top level view as a View-Controller, which passes data from the stores to the views through the props. The nice thing about this is that you can just print out the state of the view-controller at any point and get the entire state of the app.
|
|
#
¿
Dec 9, 2014 22:40
|
|
|
Thermopyle posted:Flux only recommends that for sufficiently simple hierarchies. They recommend inserting view controllers further down your hierarchy when the complexity becomes high enough. The impression I got was that the default was a single view-controller, and you should only use multiple view-controllers if your app is sufficiently complex. If at all possible you want to keep to a single view-controller. I'm not sure how much stock I put in that right now, but that's the recommendation that I saw.
|
|
#
¿
Dec 10, 2014 03:48
|
|
|
Thermopyle posted:That's literally what I just said. There's a semantic difference. AFAIK the Flux docs don't really "recommend" adding additional view-controllers further down your hierarchy, they consider it more of a necessary evil for hugely complex stuff. The example Pollyanna gave had 3 elements: Blogpost, CommentsBox and CommentForm. At that point, my understanding is that you should still be using a single view-controller, and really you should still be using a single view controller for systems that are quite a bit more complex than that. I'm not sure how I feel about it in practice but one of the goals of Flux is to have a single point of entry for data in the views and you lose that once you move to multiple view-controllers.
|
|
#
¿
Dec 10, 2014 16:09
|
|
|
One big thing to remember is that most Single Page Applications (React, Angular, whatever) will still have a backend somewhere. That backend won't be fully featured usually but it's still where you go if you want some user data or whatever.
|
|
#
¿
Jan 10, 2015 00:16
|
|
|
Misogynist posted:The backend will be completely full-featured, it just won't render full HTML pages whenever you click a button. It's more helpful to think of the difference in the interaction model being at the client end, not the server end. The server can still do whatever it wants. I meant not fully featured in the MVC sense. When you have a single page application you stop needing the templating and everything that the View layer has, so you end up with a very simplified system. The bulk of what you care about is in the model and the controller simply does routing and possibly some transformations. There are even frameworks now that focus on acting as RESTful interfaces and are simplified/specialized compared to fully featured frameworks.
|
|
#
¿
Jan 10, 2015 17:47
|
|
|
Misogynist posted:It depends? I know this. I was answering a question for someone that wanted to know where CRUD went in an Angular app. There's some cool stuff with isomorphic React/Flux applications that execute the same code on the server and client as well, but that's not helping anyone with a basic Angular app.
|
|
#
¿
Jan 12, 2015 01:20
|
|
|
TildeATH posted:Oh, wow, I like React--I don't even know why. I guess this is how it works? Play with MVCs until one matches your own particular flavor of js Stockholm Syndrome? If I were making a react app that can work with permalinks I'd probably use Flux to encapsulate the state and then have a portion of the bootstrapping javascript build the flux state based off the url parameters.
|
|
#
¿
Jan 25, 2015 03:03
|
|
|
TildeATH posted:Is there a good pattern for that which you could point me to? I'd assumed I'd use Flux like that, but I wasn't sure where to translate from permalink to state would go in this setup. There's a place where you first call React.render(). Just make sure it gets done before that happens. You'll have to decide on how you do routing and you'll have to figure out your Flux implementation and both of those will change things slightly. I'll be on a plane tomorrow so I'll have some time, I might try to whip up an example app while I'm bored.
|
|
#
¿
Jan 25, 2015 05:42
|
|
|
TildeATH posted:Is there a good pattern for that which you could point me to? I'd assumed I'd use Flux like that, but I wasn't sure where to translate from permalink to state would go in this setup. I felt lazy on the plane but if you look up Fluxible there should be some examples that do similar things. It tries to be an isomorphic framework so it does a few more things but it should give you some ideas.
|
|
#
¿
Jan 26, 2015 04:28
|
|
|
The Wizard of Poz posted:Unfortunately the major thing I'm struggling with is module management / building. I'm using the RequireJS syntax (using module.exports) so I need something to build these smaller JS files into bundles. Something that supports building to multiple output files is a must - basically my dev-JS looks something like this: For the record, RequireJS is AMD and tends to look something like this: code:If you're doing the second one then I'd have to ask what you're using to compile it. Is it browserify?
|
|
#
¿
Mar 5, 2015 03:38
|
|
|
IIRC I fixed that issue by importing vinyl-buffer and sticking '.pipe(vinyl_buffer())' in between pipe(source) and pipe(uglify). EDIT: This one https://www.npmjs.com/package/vinyl-buffer their use case also shows it between source() and uglify() NovemberMike fucked around with this message at 05:22 on Mar 5, 2015 |
|
#
¿
Mar 5, 2015 05:18
|
|
|
Noam Chomsky posted:Flux is an alternative to MVC. Flux arguably is MVC. It doesn't look like a Rails style MVC pattern, but if you look at classic MVC (which has the same unidirectional data flow) there's a lot of similarities.
|
|
#
¿
Nov 30, 2015 04:01
|
|
|
Thermopyle posted:Facebook engineers like Jing Chen, Peter Hunt, etc have specfically called out Flux as being an alternative to MVC, and to be honest, I think they're right and I certainly put them way ahead of your average front end developer in terms of experience and knowledge. No, Flux is literally a textbook case of MVC. Remember, MVC wasn't originally a web thing, it came from Xerox back when Microsoft and Apple were looting it for good ideas. Flux is different than Rails style MVC, but what Rails does isn't really classic MVC.
|
|
#
¿
Dec 11, 2015 07:06
|
|
|
Thermopyle posted:Yeah, it took me awhile to get past that feeling. Sometimes a components state is just a components state, man! This is really important, stateless components are cool but some things are stateful and trying to remove the state will be more complicated than just going with it. Hammers for nails and screwdrivers for screws instead of hammers for everything, if that makes sense.
|
|
#
¿
Dec 16, 2015 20:36
|
|
|
|
| # ¿ May 2, 2024 10:05 |
|
|
abraham linksys posted:tangential to the current discussion: having done React TDD at my last gig, and now working on a codebase where I haven't written any tests for components (just Flux stores)... I feel like in general people that do TDD can tend to test too much. High value tests will verify that nothing important breaks, and in a react app I'd generally consider the store updates, state changes for complex components and ajax calls to be the important things. Test those and I doubt you'll run into any huge problems that more tests would have helped on.
|
|
#
¿
Dec 18, 2015 08:02
|
|