31–40 of 53 posts
I feel like every new architecture for flux lately comes at the cost of a lot of code complexity. The global state is becoming extremely common too, and it feels like a big anti-pattern. Not really a fan. I do like the more pure-flux Alt at the moment. I felt quickly put off from Redux after going through docs for a while.
I feel like every new architecture for flux lately comes at the cost of a lot of code complexity. The global state is becoming extremely common too, and it feels like a big anti-pattern. Not really a fan. I do like the more pure-flux Alt at the moment. I felt quickly put off from Redux after going through docs for a while.
databases are global state (The design pattern here is separation of code from state. OOP couples code (methods) and state (members))
Earlier quoted context omitted.
Many developers are capable of learning a second language. If they are stupid about hiring they will insist on experience with ClojusreScript. And lets face it most companies will do that.
Really? Good luck convincing good JS developers that they should actually be doing Clojurescript at work instead. Maybe you'll have better luck at a local frequent clojurescript meetups (probably doesn't exist).
However, if I were to give a presentation talking about how I took X and rewrote it as Y in Clojurescript, and the benefits of doing that -- time, ease of debugging, code readability -- I'm pretty sure that they would not dismiss it immediately. (Of course, this would require me to actually learn Clojurescript well enough to rewrite my JS things in it. ;))
Maybe it's just my peers :-) but this highlights to me why I've been reluctant to adopt React. I keep getting eye rolls about not using it - but everyone I encounter seems to in the process of still figuring out application and architecture basics? We weren't an Angular shop, so never had the problems that React seems to target with one-way, etc.
I've found that I sometimes err in the direction of making components too granular, when this makes the data flows more complex.
Boundaries should exist for encapsulation, but also for change management, reusability, and interfacing with data.
Yes, components can be misused.
I've found that codebases such as rails apps often have so much boilerplate and blind following of conventions (equating to many, many lines of code) that the more fundamental issues like flawed domain modeling or incorrect abstractions are rarely even considered a problem.
Maybe it's just my peers :-) but this highlights to me why I've been reluctant to adopt React. I keep getting eye rolls about not using it - but everyone I encounter seems to in the process of still figuring out application and architecture basics? We weren't an Angular shop, so never had the problems that React seems to target with one-way, etc.
It takes a while to get a sense of appropriate component boundaries. Like other decisions, this involves tradeoffs. I've found that I sometimes err in the direction of making components too granular, when this makes the data flows more complex. Boundaries should exist for encapsulation, but also for change management, reusability, and interfacing with data. Yes, components can be misused. I've found that codebases su…
A lot of "React" excitement folks shared with me had more to do with using Webpack and ES6, which you can use with other frameworks.
> Om solves this problem with an abstraction called Cursor, which lets us focus on a path of the global atom and offer the same API as atoms. This allows views to treat the substructure as their data source and even modify it with the same operations as the Atom. I wrote a simple implementation of this concept for using it with atoms and immutable data. FWIW Om Next moves away from cursors and towards something close…
> Om Next moves away from cursors and towards something closer to GraphQL/Relay queries. Can you elaborate, I watched the Om Next talk i think you're referencing and recall David saying this, but I do not really understand why or what Cursors have to do with GraphQL/Relay as they are separate concerns. (Cursors are a way to update deeply nested data structures and don't do I/O, GraphQL and Relay are ways to coordinat…
What makes Om Next special (or so is the hope, very little specifics are available yet, but the author that makes these claims has a stellar reputation) is that the query syntax gracefully handles component composition and removes a lot of the "magic" of maintaining reliable link with data residing on the server.
Earlier quoted context omitted.
As I understand it, immutability makes management of state on complex objects easier to deal with. Whereas ImmutableJS the library makes immutability performant in JS. Someone please correct me if I'm wrong because I cannot seem to locate my source anymore, but I believe what ImmutabilityJS does is not actually deep-copy complex objects, but reuse references to nested objects that have not changed. Such that you get…
When you use Immutable JS, you are taking a slight performance hit. You are creating a new object every time you change anything and returning it. But the benefit of not having to worry about unexpected changed or sometimes referencing something you didn't mean too is great. The added performance can come from the equality checks. Like, do not do anything if newState === oldState. This has added benefit with somethin…
So if you are replacing some in-place array mutation with Immutablejs code, this will use slightly more memory. However, if you are replacing native .map, .reduce, or .filter code with the equivalent Immutablejs, you will actually use less memory, because the built in methods clone the entire object.
This feels similar to NuclearJS[1], which I've yet to use in anger, but seems like a pretty nice wrapper on top of using one big immutable data store. [1] http://optimizely.github.io/nuclear-js/
Earlier quoted context omitted.
It takes a while to get a sense of appropriate component boundaries. Like other decisions, this involves tradeoffs. I've found that I sometimes err in the direction of making components too granular, when this makes the data flows more complex. Boundaries should exist for encapsulation, but also for change management, reusability, and interfacing with data. Yes, components can be misused. I've found that codebases su…
Yes true, and to be clear, I think React is fine on it's own. It's just that from my view it's not fundamentally so superior as to warrant rewriting a decently structured app written in one of the other JS frameworks from the past few years. Especially if folks then go and have to reinvent/relearn, well, everything. A lot of "React" excitement folks shared with me had more to do with using Webpack and ES6, which you…