Why I moved from Angular to React
robinwieruch.de
robinwieruch.de
For me, after finding out the core concepts of React (views are pure functions, functional composition etc.) are actually functional programming applied tastefully to rendering, I finally realized the elegance of functional programming, and since than I've been merging these concepts into my programming methodologies.
Similarly, I'd give a shout to MobX for showing me how observables can be used in practice. For the longest time I'd wanted to learn it, but I'd choke on the syntax and the generality of common libraries. Showing how MobX worked to simplify React code, gave an instant sense of success and things clicked afterwards.
It's a start... because it brings the concept to Javascript, a language that I'm already familiar with and have a build chain for.
If one is going to switch languages, then you can consider the whole sweep of compile-to-JS languages. Elm is pretty nice in that scenario, and pairs well with my use of Elixir on the backend.
And sadly that's the biggest problem the upcoming languages/frameworks face.
In React, a component is made up of code which has HTML inside it.
In Polymer, a component is made up of HTML which has code inside it.
They're actually the inverse of each other but the result is almost exactly the same - Both libraries allow you to build components which contain other components and both provide clean encapsulation.
One of the reasons why I have a slight preference for PolymerJS is that it's much simpler and works with existing HTML concepts (they didn't need to invent a new debugging panel, a new DOM model, a new approach to CSS styling or an advanced state management architecture like Redux to make it work) - Instead, they leveraged existing web technologies. For example, Polymer provides really nice CSS style encapsulation. In PolymerJS, the <style> tag only affects the component in which it's declared (potentially including sub-components but not parent components).
It makes CSS really easy to use/maintain without actually reinventing it. You can do cool stuff like allow a sub-component's style to change automatically as you move it from one parent component to another. You don't need any special module or library or special styling logic; just a <style> tag declared at the appropriate level in your component tree/hierarchy is all you need.
That said, the React community is massive and because of this, there are tons of modules and tools around it so it's hard to beat now - It seems that pretty much every problem that React has introduced has since been fixed.
Also, fwiw, Facebook didn't invent Redux, Dan Abramov and Andrew Clark did _before_ they joined the React team :)
I don't like this at all. I want all the styles to be encapsulated to the component only. It shouldn't matter what parent component it's in. Polymer's CSS automatically spills over into the child components.
Hm? No, the opposite, the shadow DOM provides CSS encapsulation.
"potentially including sub-components but not parent components"
I find that often though, I like the host component to affect the style of child components - For example, let's say we have 2 container components which hold a list of items; one container component shows its items as rows and the other component shows items as thumbnails (with a picture). In this case we want the parent container component to affect the style of the child item (thumbnail vs row). If we were to drag an item from one container and drop it into another, we would want the style (thumbnail vs row) of the new parent container to take effect on the child (without having to imperatively update styles in the child).
The danger in traditional (non-WebComponents) CSS is not the cascading aspect of it; it's the fact that it's global. If you localize CSS to components such that it only cascades downwards in the DOM hierarchy, then it solves all your problems.
Also, because of the CSS specificity rule, style properties defined in the child will overwrite those from the parent, so the child always gets the last say about how it looks - With this approach, the child can effectively decide which CSS properties its parent is not allowed to modify.
This really scares me. We spent a lot of effort removing inline styling from HTML with CSS, and yet it still creeps into our HTML. We also have created a lot of <program language dejour> "template" languages (e.g. PHP, Python, ERB, etc.) mixed in with HTML, which also tends to end badly (logic buried in HTML that is hard to find and hard to reason about).
How does React solve the "everything mixed into HTML" problem? Are we going down the same path that ended badly last time?
So we've seen a push toward components that mix technologies, but separate concerns. And it's been great.
People learnt that mixing behavior and presentation was bad but that was a specific case of a more general rule.
In fact - "separation of concerns" is itself a specific example of an even more general rule which is something like "Make code easy to reason about" or "reduce side-effects" or similar. It's hard to give advice that doesn't sound hand-wavy and empty without getting specific. But as soon as you get specific you exclude alternative solutions to the same core problem.
Programming is largely about managing complexity and there are many ways to achieve that. But learning how is a subtle art indeed.
The reason why we need software design principles is because software changes. Software design principles are methods of organising software that make it easier to implement changes.
When it comes to changes it seems that the golden rule that makes things easier for humans is: things that vary together should be together (and things that tend to vary separately should be separate). Its interesting to think about why this is the case, but I'll skip that and take it as an axiom.
There was an article (which I can't recall the URL of) that argued how all the SOLID principles stem from this basic rule.
Single responsibility principle: it follows directly from the above rule: A class should have only one reason to change (keep things that could change separately separate)
Open/closed principle: Interfaces should vary significantly less than their implementations, so that both producers and consumers of those interfaces can vary independently of each other. e.g. Shape can have a method draw that takes a canvas interface: now we can vary both the canvas implementation and the different shapes independently.
Interface segregation principle: don't put too many things in an interface, they might vary differently. Make separate interfaces based on consumer types since change in consumers are more likely to affect changes in the interfaces they use, and having one interface for two types of consumers means two separate sources of change that vary differently.
Map / filter vs for loops is simply this principle applied in the small. The code to initialize an empty data structure, iterate through all the elements applying a function and then store the resutls in the data structure is always the same. The only thing that changes is the function that defines the transformation. Since its a concept that is very common and never changes, it should be separated from the transformation itself (which changes often and depends on the problem domain) and be given a common name (map)
It then follows easily that separating the component template from the code that manages component state doesn't really help. Its fine in server-side languages where the template is simply the final function in the data transformation pipeline for that request, with multiple potential views on the same data (html, json, xml etc). However, on the client side most of our code manages changing state closely tied to the DOM based view: for example, the sort column and sort direction of a table, or the current item selection, etc. The kind of state we keep is directly tied with how we present things (sortable table? => sort column and sort order; expandable tree? => expanded/contracted state for all branches, etc). As our view/component requirements change, the state we keep for it (and the way we manage it) also changes.
And since things that vary together should be together...
In the long run, the SPA craze will backfire, big time. Rect components are not semantic and not declarative. There is no way to examine them without executing code. This is an elephant in the room most fronted developers willfully ignore right now.
If you can pin down your definition then I'd be able to provide a more concrete opinion.
> The notion of separation between information, presentation and behavior couldn't be any more fundamental.
Fundamental to whom? Outside of web development this separation was never fundamental - see the post above regarding "separation of concerns" - which is a much better candidate for a "fundamental principle"
Separating css, html, and js makes sense when you're writing a document, and the content is the html and the css is strictly formatting.
It makes less sense when you're writing an app, and the styling of the html is an integral part of what is being created. The javascript works the same way; it's often integral to what's being rendered, not just patchwork adding small amounts of functionality to an existing document.
But probably most importantly is that react gives you a different way of separating concerns: it's very easy to put different chunks of the UI into different components/files, so your app is divided by functionality, instead of divided by technology. Keeping the html (and sometimes css) with the js that uses it helps increase the cohesion of small units in your UI that intimately work with each other, while separating those from other js/html/css for other units.
Preferably, all local concerns of a component (not referring to the React component class but the abstract component: a single unit within a larger project) would be in one place. For the front end of a web app this includes structure, styling and behavior. So it makes sense to define the structure (HTML), styling (CSS) and basic behavior (animations, different states it can exist in, etc.) in one place.
React models this using JSX, inline CSS (or CSS loaders) and the React component API.
Now we have ways to use these patterns and still have them be maintainable, which means it's time to reevaluate that previous effort. Co-locating styling with structure and behaviour tends to make our lives easier.
I can go one step further, I work on a React-based website which achieves straight 'A's on webpagetest and scores 100 on Google Pagespeed (Mobile and Desktop), this took far less effort than it ever took me to achieve worse results on previous stacks.
The component model (with co-location of styles) is incredibly powerful, and it works, give it a try.
Styles work very well on the per-component level. The best and worst part of CSS is the "cascading" part.
The thing is that with React, you aren't really writing HTML. Sure, JSX makes it look like it, but it's not a template, it's actually just a Virtual DOM element tree. This means it doesn't have the same issues as many templates.
> logic buried in HTML that is hard to find and hard to reason about
That's a complete non-issue with React and much more an issue of the traditional way of breaking it up in different files which look separated but in reality are extremely entangled.
Also, regarding the CSS questions, setups like CSS Modules in a Webpack build make the CSS very maintainable. Not to say there aren't drawbacks, but IMO having the classes be dynamic makes everything way more flexible. And, tools like hot-module-reloading make front-end development so much more enjoyable.
Styling is syntactically really just markup decorators after all, although CSS may end up Turing complete if it isn't already :) (this is probably a bad thing)
JS is actual programming language an you can split out styles to separate style library without using .css files.
You could also split out render function (that uses JSX) or its parts to separate file. But you'd rather keep it close to logic that interacts with it and keep the whole component, logic plus presentation small enough to understand with a glance.
That on scale it's not easy solvable.
And that's the reason why we are looking for other approaches to isolate/share the main functionality.
There are many things that the "React ecosystem" has taught me that I can apply to any future application I build regardless of the stack, but many of my problems were solved in little time because the SO answer to my questions also used React, or the answer came in the form of a React component I could plug in and not worry about.
Maybe when Vue's community is as thoroughly developed I'll try that out again. Right now it's hard to find a reason to switch.
You are instead sent (after confirming your email) to a site that lists the 'minimum price' of the book as free, gives you a price slider that cannot go bellow 14.99 (and the "additional information icon" when hovered, shows a minimum price of 14.99, contradicting the page's own previous claim)
A resolution that allows other users to aquire the free ebook is preferred, but removing the offer of a free ebook would also solve the problem.
I had tried as a student before. Just to make sure, I tried again. Slider wont come to less than 14.99.
See screenshot: http://5cm.ru/view/i7/AwQ7.png
Note that it says free on the page, and minimum=14.99 on the dialog.
Also note that student is selected
I'm obviously biased, but using Angular (2+) with typescript and ngrx (observable based redux, essentialy) has been really nice to develop with.
I'm not sure what you mean about components...Angular is component based. Are you referring to native web components?
Manage an stream of html comming from a backend CMS. An upgrade their DOM.
I also don't get why two way binding is difficult to reason about. Can somebody please give me an example?
So I'm asking: what are the best real alternatives that work natively on mobile?
React-native provides react with primitives that are native (such as View, Button etc...).
Navigation is also native (as in the transitions are native).
Until angular or vue can run withou the dom (which is the #1 reason for performance issues in wwb apps), they cannot compete with react.
Those are two different problems: what is the best framework for our web front-end vs what is the best framework for our iOS front-end. If you want to normalize on React for both, what is the problem that you are solving by doing that?
NativeScript also has a novel idea how to implement multithreading in JS, which is commendable.
It seems to me that React + JSX are perfect for "divitists" and devs who use a h3 because its font-size has the desired value.
I'm not being sarcastic, I genuinely can't understand why a good web developer who cares about the meaning of a HTML document should like JSX.
Especially when you have a news site getting millions of views, you simply can't afford 1 second on page load to download, parse, and eval React and your data model for little gain.
I've seen devs that are so infatuated with React and "isomorphism" that they will use it as a hammer for every screw they come across.
I've found that React generates trustworthy HTML, letting me focus on business logic and the interesting parts of development. I've never come across a scenario where React threatened the coherency of my code (other than the data attributes that are now optional, thankfully).
A good html developer will still use best practices when using React, a bad one won't. What's the difference?
That's why this question began to slowly form in my mind.
[edit: phrasing and grammar]
Practically speaking though, I'm evaluating high-level frameworks like Blueprint, Clarity, and Element, vs. the prospect of becoming a bespoke framework provider myself (probably not).
If I'm starting off with a respectable set of components, then I can adapt to the lower level libraries as necessary.
Now, when reading Hacker News, a lot of people post about React. I have never learnt before. Maybe, I am late to the party. I must dig posts about React to know its use cases.
Here in Australia it's all AngularJS (they're all jobs converting 1.x to 2.0) and sadness :(