I'm really confused by this comment. Unless I'm missing something about this specific library, if you pass new a new `data` prop to the chart, it will re-render, so live data is the same as any other data. This is true for any react component.
1,018 karma · joined May 1, 2015
Agreed. Hearing about the minutiae about someone's task is tedious. To me the daily scrum is like getting home and asking your significant other "how was work today?". Boring question, boring answer.
I definitely prefer the asynchronous approach. That way if I don't care about what you're working on (or vice versa), we don't need to waste time standing in a room together.
Isn't that the point? Since Elm is a pure, strongly typed language, it introduces a lot of constraints. You can't mutate anything, there are no side effects (only declared effects captured by the type system), and the only architecture you can use is "The Elm Architecture". However, those restrictions will keep your code sane and the compiler almost guarantees that your code will work. It's a pretty fair trade-off if you ask me.
I will continue to shill for Elm[1], like I always do.
The first one decided to go "off the rails" and made up their own architecture based on Uncle Bob's SOLID design principles or whatever. We weren't allowed to use ActiveRecord, which is a huge part of how you handle domain logic, validations, relationships, cascading deletes, and data consistency in Rails. Instead of ActiveRecord Models, we had `repository` classes which basically had a bunch of raw SQL queries, we had `interactor` classes to handle all of our domain logic, and our controllers were just called `interactor` methods and returned the result.
The general architectural ideas came from a good place, but going that hard against the "Rails way" made basics tasks extremely difficult. We couldn't use any external Rails gems because our architecture violated the basic assumptions that gem authors made. We had to hand roll all of our validation logic because we couldn't use ActiveRecord. Our DB raised non-NULL exceptions all over the place because people would forget to validate certain fields, or didn't know that certain fields were required because there was no model class to clearly articulate the schema. After just 6 months the code was already a mess.
The other company I worked for embraced the "Rails way" completely. The code base accumulated a ton of technical debt and general jankiness along the way, mostly due to constantly changing business logic and integration with 3rd party services like Salesforce, but the code base was surprisingly easy to work with. The company shuffled people to different teams a lot and it wasn't that hard to onboard new devs into a given project.
What I'm trying to say in a very long-form way is that Rails, when used as it was intended, works pretty well for medium to medium-large projects. You just have to do what the framework wants you to do. It might seem restrictive, magical, or maybe even stupid, but it will prevent a lot of confusion and pain. If you really dislike the Rails ideology, it's better to just avoid the framework entirely.
http://i.dailymail.co.uk/i/pix/2015/10/03/00/2D0746BE0000057...
[1] http://www.drakenexpeditionamerica.com/2016/06/07/cooking-on...
Post.select("posts.*, COUNT(comments.*) AS comments_count").joins("LEFT JOIN comments ON comments.post_id = posts.id").group(:comments) Post.select("posts.*, count(comments.*) as comments_count").joins(:comments)Email: frank.r.bonetti at gmail dot com
I'm a full-stack web developer with 4+ years of experience. I specialize in React.js, Ruby on Rails, Firebase, CSS, MySQL, and PostgreSQL. I'm also an avid proponent of the Elm language and frequently contribute to open source. You can view my github profile here:
I pretty much exclusively work with startups and I excel at building new products from scratch. Aside from the dev work I do, I also work with my clients to help them build the right product to fit their needs.
Full skill set:
Languages: Ruby, Javascript (ES5 and ES6), SQL, Elm, Haskell Databases: PostgreSQL, Firebase, MySQL, Rethinkdb Frameworks: React (with Redux), Ruby on Rails, Express, Phoenix Other: Socket.io, websockets, Redis
What's not fun is learning 10 different ways to handle promises, 4 different build tools, several frameworks, and dozens of new libraries over the course of a year just to keep up. By the time you reach a level of mastery over one of these tools, it's already been replaced by something else! I mean it's great that the tools are getting better, but it's really painful to deal with the constant churn.
/rant
To create a proper React single page app, you need React, Redux, lodash, react-router, webpack, Immutable.js, babel, npm, redux-thunk, isomorphic-fetch, webpack-hot-middleware, and ton of boilerplate and configuration (which everyone does differently). You can try to assemble this yourself, or choose one of hundreds of starter projects on Github.
A comparable Elm app is a lot simpler. It consists of Elm, a router such as elm-transit-router, and maybe webpack if you want to watch and minify your compiled javascript. Especially now with the new 0.17, Elm forces you to use the standard Elm Architecture, so you don't waste any time thinking about how to structure your app and there's very little boilerplate as a result. On top of this, Elm is statically typed, functional, and simply a joy to work with.
I'm really surprised the author went through all the trouble of making this, considering that you can handle dynamic styling via inline styles in React.
class MyComponent {
render() {
return (
<div style={{color: this.state.color}}>
My Text
</div>
);
}
}