|
The Merkinman posted:Apologies if this had been covered. One of or devs wants to use AngularJS for or ecommerce site. Watching the egghead.io videos it seems AngularJS (and the other frameworks in this thread) are meant for generating, then manipulating, content. http://stackoverflow.com/questions/13499040/how-do-search-engines-deal-with-angularjs-applications Does that help?
|
#
¿
Dec 1, 2013 20:40
|
|
|
|
| # ¿ May 2, 2024 07:22 |
|
|
Pollyanna posted:Would it make sense to try and MVC that or is that better done through plain HTML? You're confused. But anyway, Angular will do what you need, easily. I don't know if it's the best tool for the job, but for such a very simple project I doubt you're going to see much difference between any of the tools as far as the complexity of implementation goes.
|
|
#
¿
Dec 4, 2013 20:03
|
|
|
Pseudo-God posted:In PHP, if I want to connect to a DB, I usually set the DB connection details in some config file, or even the page source itself, and this information is never revealed to the end-user. However, I cannot figure out how to hide these details in a JS only app, where everything is exposed to the browser. Is it possible to store confidential details, such as DB passwords, in a JS file or similar, but prevent them from being read by the user? 1. You need to build a server-side layer between your DB and your client-side apps that communicates in JSON or whatever. 2. It's not possible to hide the auth info to a DB or the layer mentioned in the last point from the end-user. You can require logged-in users and that's about it.
|
|
#
¿
Dec 10, 2013 17:46
|
|
|
Since Maluco Marinero convinced me to try out React.js a few days ago I was looking into React.js support in my favorite IDE, PyCharm. I noticed that WebStorm (of which PyCharm is mostly a superset of) has a new update with greatly improved AngularJS support. https://www.youtube.com/watch?v=rlNmYgNdOkM In particular I'm really liking the AngularJS refactoring and autocomplete support. Just thought I'd throw this out there. (In case you're wondering, WebStorm doesn't yet have React.js support, but it's coming.)
|
|
#
¿
Mar 29, 2014 16:49
|
|
|
Mr. Wynand posted:Use a grid component of your choice? It is indeed a common thing. This reminds me. I'm getting ready to do a UI that will have a ledger in like Quicken or whatever. Anyone know of any good components out there made for this, or easily adaptable to it? I've been putting it off because I don't really want to build it.
|
|
#
¿
Apr 3, 2014 21:53
|
|
|
isochronous posted:When it comes to grid controls, my favorite so far has been Kendo UI's grid control, but that's like saying my favorite bone to break is my little finger. Overall I think general-purpose grid controls typically indicate a lack of design focus, but if there's one good place for grid controls, it's in spreadsheet-like applications. Greve posted:http://jsfiddle.net/fimiak/QSu2p/ I mean, angular is great, but other frameworks have their merits as well and it's a shame to see them not getting as much attention. Or, rather, I don't care that they don't get as much attention, but they get pretty much zero attention relatively speaking.
|
|
#
¿
Apr 10, 2014 17:19
|
|
|
Chenghiz posted:Okay, buckled down and did the whole page with React, no problems with jQuery Mobile at all and it's really loving easy to modify. The reusability of React components makes it so that the further you get in to a project, where you've got your components mostly fleshed out, the easier it is to make minor or major modifications. Or at least that's what I've found so far in my couple of weeks with React.
|
|
#
¿
Apr 12, 2014 19:10
|
|
|
As we've had a decent amount of discussion around React lately, I'm debating tearing the React component I built around the Select2 jQuery widget out of the project I'm working on and putting it up on github so people can get an idea on how to use jQuery stuff with React. I've got to do some work on it to make it a bit less tailored to exactly what I'm doing is the only reason I haven't just done it. Is anyone interested in seeing that?
|
|
#
¿
May 14, 2014 23:52
|
|
|
KARMA! posted:Yes. Subjunctive posted:The React team is. Ok, I don't know how good this is as I've only been fooling around with React for a month and JS for hardly any longer, but... There's a demo here. Link to the Github on that page as well. If anyone wants to work on it and help flesh it out I'm game for some pull requests or whatever.
|
|
#
¿
May 15, 2014 22:46
|
|
|
Wheany posted:I think I want to use React and Bootstrap together in a project. The reason is that React seems pretty nifty for building view components, and I like Bootstrap's layout, especially the responsive layout bits (from the little I've seen over a coworker's shoulder). It works just fine. I've been using Bootstrap with React for a couple months...
|
|
#
¿
Jun 27, 2014 15:07
|
|
|
caiman posted:I make primarily non-database driven websites. Would learning Angular benefit me at all? Angular is cool, but be sure and look at Facebook's React as well if you're just looking for new things to learn to make building interactive websites easier. It clicks with me more than Angular. -- I've been looking at Google's Polymer for an hour or so as I think their new Material Design is fantastic looking. Polymer is a pretty slick take on Web Components. I'm not sure how useful it will really be, though. The big sticking point for me is that right now I don't see how to get it to work with React (which most of my current projects are built with), and it doesn't seem to offer enough to replace React.
|
|
#
¿
Jun 30, 2014 21:39
|
|
|
Newf posted:What can you skinny jeaned, mustachioed folk tell me about integrating some of these hip js frameworks with an asp.net project? I'm building a site whose back-end is entirely c#, but whose front end will benefit from the snappy nature of client-side page generation rather than constant (say, every 5-10 seconds) client-server page render requests. At a high level it doesn't matter what your backend is as long as it can deliver data to the front end. Typically this is via JSON, so if you can generate JSON with your backend, you just set up an API for javascript on your frontend to GET/POST to and then write a bunch of HTML/CSS and javascript in your framework of choice.
|
|
#
¿
Jul 8, 2014 15:43
|
|
|
QPZIL posted:Are there any good blogs or sites to follow to keep abreast of the latest trends in front end development? I feel like every week I come in to work and learn about a new framework or language or something - not that I will be using any of these quirky new frontends, but it's still fun to read about. http://sidebar.io/
|
|
#
¿
Jul 14, 2014 16:57
|
|
|
Pollyanna posted:We should put that in the title. Goddamn, just pick one loving framework and learn the ever-loving poo poo out of it.
|
|
#
¿
Jul 16, 2014 17:35
|
|
|
Newf posted:I'm playing with the tutorial for reactjs.net, and I've been pulling my hair out trying to find some misplaced comma, or other such error, in my jsx file which is causing it to fail to be converted and delivered to the client as javascript. There has to be some tooling that will help me with this, but I can't find it. My guess is there's not a lot of people here using that, but there are a few of us using React outside of .NET. Thus, you may be better off just posting your JSX and getting us to look at it. In my experience there's not a whole lot of JSX tooling yet.
|
|
#
¿
Aug 10, 2014 19:33
|
|
|
Newf posted:There was a pair of ()s that should have been {}s, but the specific instance is hardly the point. I'm still really lovely with JS in general, but it seems to me that the only recourse for a page flat out not displaying is to revert a step or two and go again - beats the hell out of 'there might be a missing comma in this 7000 line file'. Well, if you check the console there's often enough information in the logging to figure out what you've messed up.
|
|
#
¿
Aug 10, 2014 20:33
|
|
|
Lumpy posted:I wrote a very basic blog post about mixins in react: http://simblestudios.com/blog/development/react-mixins-by-example.html Nice post. I like mixins. I like them in other languages/frameworks too. One thing to note is that you should try to avoid getting too clever with your mixins. It gets hard to reason about the functionality if you get too many implementing the same method.
|
|
#
¿
Aug 29, 2014 22:39
|
|
|
HaB posted:You sound like me when I first started using Angular. This is why, even now that I'm comfortable with Angular, I don't really like it. I mean, it's OK, but it doesn't bring enough to the table to make me think the tradeoff of dealing with it's ... different ... nature is worth it.
|
|
#
¿
Sep 2, 2014 20:41
|
|
|
I'm whipping together a Django backend that exposes a CRUD RESTful API that has about a dozen models with various relations. The backend serves no HTML at all. I'm going to put together a web frontend and I'm looking to try some new JS libraries/framework. Just looking to expand my toolbelt and learn some new stuff or maybe become more familiar with things I've dabbled with before. Any recommendations for anything you like for managing the backend and frontend objects and keeping them in sync?
|
|
#
¿
Sep 9, 2014 18:45
|
|
|
Pollyanna posted:I think my question is more on understanding and implementing a more general model-view-controller setup. Like, make a simple one from scratch in Ruby or Python to understand why the gently caress we'd want to do it and what the important bits are. I know that frameworks differ, but there has to be some sort of commonality, right? This isn't what you want to do. What you want to do to really understand what I think you're wanting to understand is (as Newf mentioned) develop a complex-ish project from scratch without using a MVC framework.
|
|
#
¿
Oct 5, 2014 02:37
|
|
|
"Daniel Dennett posted:There's nothing I like less than bad arguments for a view that I hold dear.
|
|
#
¿
Oct 7, 2014 18:09
|
|
|
There's an RC out for React .12.
|
|
#
¿
Oct 19, 2014 00:48
|
|
|
Pollyanna posted:Aha, that's done it. Thanks 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. Really, spend a week getting used to Flux. It will solve your problems.
|
|
#
¿
Dec 9, 2014 16:54
|
|
|
NovemberMike posted: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. Flux only recommends that for sufficiently simple hierarchies. They recommend inserting view controllers further down your hierarchy when the complexity becomes high enough.
|
|
#
¿
Dec 9, 2014 23:24
|
|
|
Pollyanna posted:One problem that Flux has is that it exposes too much of the internal wiring, it feels like. Being expected to build an EventEmitter for every Store I make feels like busy work and like something that could be automagically abstracted away for me. This is mostly an illusion. You create a store base class with your common functionality like addChangeListener, removeChangeListener, emitChange, etc, then you just extend that for each of your stores. something like JavaScript code:Then when you want to create a store, you JavaScript code:I mean, there's a hurdle to implementing Flux because it works differently from most other patterns so it's hard to wrap your head around. Once you've got it where you really get it, it should seem super easy.
|
|
#
¿
Dec 9, 2014 23:40
|
|
|
NovemberMike posted: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. That's literally what I just said.
|
|
#
¿
Dec 10, 2014 05:02
|
|
|
NovemberMike posted: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. From here: quote:Occasionally we may need to add additional controller-views deeper in the hierarchy to keep components simple. This might help us to better encapsulate a section of the hierarchy related to a specific data domain. Be aware, however, that controller-views deeper in the hierarchy can violate the singular flow of data by introducing a new, potentially conflicting entry point for the data flow. In making the decision of whether to add a deep controller-view, balance the gain of simpler components against the complexity of multiple data updates flowing into the hierarchy at different points. I'm not sure where (or if) we're disagreeing here. Thermopyle fucked around with this message at 19:40 on Dec 10, 2014 |
|
#
¿
Dec 10, 2014 18:01
|
|
|
Pollyanna posted:Maybe there's a singular top-level controller that splits off into smaller component controllers. Or something. Then technically there's a single source of data, it's just divided up. Well the single source of data is the store. The question is how that data gets to your components. If you have a sufficiently simple hierarchy, you can just get the data from the store in your top-most component and pass it via props to children. This gets rickety for sufficiently complex hierarchies or apps. In those cases you can design your hierarchy so that parts of your data goes in to components further down the component hierarchy. However, you have to be careful that you're not exchanging one rickety design for another. You can avoid the confusion of data entering your app lower down the hierarchy by designing in such a way that you have a hierarchy of hierarchies where data just enters at the parent components of the sub hierarchies and making sure you have a logical bright line separating the different areas of your app where data enters. Unsurprisingly, designing complex apps is complex.
|
|
#
¿
Dec 10, 2014 19:41
|
|
|
Lumpy posted:I'm goofing around with a Django-Rest-Framework -> React/Flux "fun" project (you've inspired me, Thermopyle!) and just want to get some opinions on how people would approach something. The app shows a list of Activities. A user clicks on one, and the details for said activities are displayed. So far, so good! Users can also sign up for Activities, and here's where my question lies. I used to get hung up on this kind of stuff a lot more often. Nowadays, I always get all of the things all of the time. I mean, it might be more resource heavy but I worry about that when it becomes an actual problem. Often it doesn't ever become a problem, and I saved myself the effort of additional code. And by additional code I don't just mean the effort of writing more lines because that's barely anything. I mean the extra mental capacity taken up by having more logic to keep in your brain when reasoning about your code. Thermopyle fucked around with this message at 18:47 on Dec 18, 2014 |
|
#
¿
Dec 18, 2014 18:45
|
|
|
Lumpy posted:But I won't feel smart if I don't prematurely optimize! Oh, I definitely understand the compulsion. I've got to consciously take a step back every once in awhile to figure out if I need to be doing what I'm doing.
|
|
#
¿
Dec 18, 2014 23:37
|
|
|
Pollyanna posted:I'm wondering how I "add" and "remove" components in React. I've got a Search Form and a Search Results component, and I always want to display the Search Form, but only render the Search Results when the search button's clicked. Would it basically look something like this? no JavaScript code:
|
|
#
¿
Dec 30, 2014 17:47
|
|
|
Yeah, that's the better way. I was just being lazy.
|
|
#
¿
Dec 31, 2014 02:13
|
|
|
HaB posted:I have only ever done it the 2nd way. I'm not entirely sure of DJANGO's reasoning behind the first. But I would say that if each ChargeCode "HAS A" Category, then category should be a sub/child object as per the 2nd example. HATEOAS
|
|
#
¿
Dec 31, 2014 20:30
|
|
|
an skeleton posted:I have a question. I'm a novice developer (been seriously developing for about a year or so) and I am finally feeling pretty proficient in AngularJS (I still kinda suck at creating directives from scratch but whatever). I kind of have the itch to learn a new JavaScript framework, I was thinking Backbone or Ember. However, I have 2 questions. It kinda depends on your goal. If you're wanting to expand your ways of thinking about the problems we encounter, I'd recommend learning React. Particularly because it's got a small API and you can read all the docs in one sitting, so it's not like you're devoting a big chunk of your life to it. Really, the more you learn, the more tools you have to solve problems you encounter. They're all good to be familiar with.
|
|
#
¿
Jan 7, 2015 06:51
|
|
|
The Wizard of Poz posted:Yep, that's what I figured was happening but wasn't sure how to fix it (very new to React). Thanks so much! I don't use Visual Studio (I use a Jetbrains IDE), but I just run a transformer in a terminal window set to watch mode so it just recompiles on the fly. Specifically, on my current project i'm using Browserify with watchify for packaging everything into a single js file. So I run this in a terminal: code:
|
|
#
¿
Jan 29, 2015 18:58
|
|
|
Maluco Marinero posted:Are you searching for a mounted element within a tree, or just a class that you can use somewhere. If its the latter React doesn't actually have a registry of classes, but you could easily create an object that'll hold class references yourself. Also, it makes me a little nervous that you're wanting to do this at all. Maybe you're using React a little...wrong-ish?
|
|
#
¿
Jan 29, 2015 18:58
|
|
|
Hanpan posted:I have several different 'panels' that I am showing on a dashboard, and the type of panel is dictated by data coming from the backend. I guess what I should do is introduce a controller that keeps a reference of all my React views and instantiates them accordingly. I just didn't want to duplicate logic if it was already part of React. If I understand your problem what I'd do is have your component that contains your panels.In your render method have code to determine the type of panel components to display and then display them. Something like: JavaScript code:
|
|
#
¿
Jan 30, 2015 19:13
|
|
|
neurotech posted:I'm excited to learn React even more now. You should be, in my mind, it's easily the best of its peers. Also, you should just go learn it. It's easy to understand, and quick to learn.
|
|
#
¿
Feb 10, 2015 23:15
|
|
|
Horn posted:Speaking of react, flipboard has released a library that replaces the dom rendering with canvas. I've barely gotten my feet wet with react but between this and the native stuff it seems like the library has a promising future. I don't have any use for that, but it seems really cool!
|
|
#
¿
Feb 11, 2015 07:49
|
|
|
|
| # ¿ May 2, 2024 07:22 |
|
|
I've been messing around with Reflux, and I think I like it better than vanilla Flux or Fluxxor. It gets rid of the concept of the Dispatcher. Actions themselves become event emitters, and stores listen to the actions they're interested in. Anyway, if anyone is having a hard time wrapping their head around Flux (which isn't terribly surprising as the pattern isn't quite as elegant as React itself), they might want to give Reflux a look. Here's a blog post that does a bit of summary of the library: http://spoike.ghost.io/deconstructing-reactjss-flux/
|
|
#
¿
Feb 11, 2015 21:21
|
|