I want to publicly thank Binaryreap3r for their professional ethical hacking service which is fast very impressive service. I'm happy to recommend to you.
Has your Social account been attacked by a hacker? Do you need to get back into your Facebook, Twitter, Instagram or Google+ account?, Have you lost your email or social media password and want to crack/recover it from computers?. Are you being cyber stalked and wish to find the source and stop the cyber predator?, Have you been scammed online? Do you need to locate and report the perpetrator?. Do you want to encrypt your data and protect your sensitive informations?. Any social engineering problem you may have. I know a white hat hacker that delivers!. He helped out with an issue and I think he's good what he does. Contact binaryreap3r@gmail.com or text +16155497267 for all your professional hacking needs.
An experienced Javascript developer’s account of learning React
141–150 of 157 posts
Re: An experienced Javascript developer’s account of learning React
#142I am confused why people think Redux is complicated. Maybe you were trying to use React-Redux? Redux itself seems incredibly simple to me, so simple that I sometimes wonder if I need a library for the functionality at all. This "Redux in a nutshell" sums up the simplicity nicely I think: https://gist.github.com/MarcoWorms/30758235f05faec844b8c06ce...
I've had the same experience. It took me about a week to "get" Redux as a new-ish dev back a year or so ago. Why do you think people have trouble with it?
I don't think people are having problem with understanding how redux work, but having problems with the shear number of boilerplate files you have to write to get anything done. Often times the speed at which you can get things done is equated to productivity.
Re: An experienced Javascript developer’s account of learning React
#143Switching to React definitely has a learning curve, especially if you are coming from old-stool JavaScript or just not used to some of the concepts in React or Redux themselves. That said, once you get your head around it things start falling into place. We're recently built a React Native app and I feel the benefits it brings to cross-platform development make that ramp-up worthwhile. A single iOS and Android codeba…
I saw a fascinating talk on Redux, I like the idea of how it manages state and the whole event sourced approach to that. I've repeatedly tried to get Redux going with either React or Vue but have found it surprisingly hard. Many outdated seed projects and installation instructions made it somewhat painful. I've played a bit with React from the more recent create-react-app and that got me started with some of it. I ha…
If you've got questions on using React or Redux, please feel free to drop by the Reactiflux chat channels on Discord and ask. I hang out there most evenings, and there's many others happy to help as well. The invite link is at https://www.reactiflux.com.
In addition, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. It includes links for learning core Javascript (ES5), modern Javascript (ES6+), React, and much more. I also published an "Intro to React (and Redux)" presentation at http://blog.isquaredsoftware.com/2017/02/presentation-react-... , which is a good overview of the basic concepts for both React and Redux.
Re: An experienced Javascript developer’s account of learning React
#144At our company, we have banned React, Angular and other "overengineered" JS frameworks. Our HTML is rendered from a standard boring Groovy server page, with some vanilla-js for DOM manipulations here and there. We have hired developers that were React fans, which quickly changed opinion that this old-school way for developing web applications is indeed better. It is faster to code, an order of magnitude easier to mai…
I've said it before here, but the best web app I've built was basically Django, with bare minimum js to handle in-page effects. I've been working on a project which is being ported to React for no reason, just because it's shiny, and it's been worst than expected. Bundling the entire website into a huge js file doesn't make any sense. In practice, every time you make the slightest change, like adding a div, or changi…
If you can build your application without a framework, do it. It's the right call every time. Not every web project calls for React, but for the ones that do it's a god-send. The alternative to me is not a minimal Django app -- it's nigh-unmaintainable jQuery spaghetti.
Re: An experienced Javascript developer’s account of learning React
#145Earlier quoted context omitted.
I am working on a web application that is dynamic enough that the standard way to build websites makes it really hard. So I started building my own version of React. Found React some time later and switched because it was better than my crappy code. Why was I trying to build React? I wanted a framework that behaved more like a video game render loop or a desktop UI framework. I wanted a framework where I could simply…
> I wanted a framework that behaved more like a video game render loop I had that thought the other day, apparently it's not so novel after all! Does anybody know of other frameworks that take this sort of approach?
Anything with a Virtual DOM pretty much.
Re: An experienced Javascript developer’s account of learning React
#146Earlier quoted context omitted.
If your web-app has even a modicum of complexity on the client side, the vanilla DOM based solution is going to get unwieldy real fast. Consider a simple list of elements to which you can add or delete items. With vanilla DOM, you’ll have to write handlers that will `$.find` the particular element, and then run a `$.remove` to remove it. To insert something, you’ll have to do a manual `$.appendHTML`. And when you hav…
To be fair diffing virtual dom is not the only way - you could also be diffing the model and only update the parts which need it. Knowing the model well allows you write an efficient diff. The problem of course is that dom diff is universal while model diff is specific to application.
or operate on document fragments
Re: An experienced Javascript developer’s account of learning React
#147Earlier quoted context omitted.
Ah, I think I see. React is a templating library. Nothing more, nothing less. It takes a state ("props"), a template ("component") and renders the DOM tree. That's all it does. (Non-templating uses like react-router are kind of hacks, rather than intended use. YMMV, of course.) However, it's more complex than previous-generation templating libraries (that had emitted strings, rather than operating on DOM trees), beca…
no disagreement on what react is. yes, I understand react can be used just to template (no one uses it this way). yes, react is powerful. yes, react provides a good mechanism for handling state and events. what i am saying though is that for some apps, you can get by with simpler templating and avoid the conplexity/power react gives you, handling state and events yourself manually. does it sound crazy? if you know it…
> react can be used just to template (no one uses it this way)
I don't know about the others but I do. Got bad experience when I've shoved logic where it didn't belong, don't repeat the same mistake again.
As the templating "got data, want a form, a table and a chart" engine it's good - exactly in a sense that I can write one template instead of multiple partials (add+update+remove). The complexity hidden underneath doesn't strike my fancy, but... it works, and saves coding time - especially because a lot of components are already written by someone else and is available on npm.
Still, it's really really easy to shoot yourself in the leg. And I found a fair share of tutorials and examples teaching those sort of things.
> react provides a good mechanism for handling state and events
No, it doesn't have those. Unless you count react-router/Redux/Mobx/whatever as React-the-umbrella-naming.
Well, there is some basic internal state management (via constructor + `setState` + `componentWillReceiveProps`) but that's about it, and IMHO it best very used conservatively, for approximately the same reasons why having logic in, say, Jinja2 templates isn't the best idea in Python world. Or maybe I just don't know how to cook stateful components properly, but last time I made a stateful component I ended up rewriting it some weeks later, extracting the state away, because it became a problem.
There is no event handling at all - except for the "props are changing, this is going to update" event, of course. All React has is `onClick`-like attributes and handlers bound to those are best left as some dispatch calls to the outside, with no logic inside the React component code whatsoever.
Re: An experienced Javascript developer’s account of learning React
#148Earlier quoted context omitted.
Parent's paste bin is ~40 lines of code (with white space) consisting of 4 functions, with what? 4 loops. If you consider 40LOC complex I don't understand why you work as a dev.
> If you consider 40LOC complex I don't understand why you work as a dev. Goodness, your snark that questions the parent's competence is not only unwarranted, it is based on an incomplete understanding of the value of abstractions in programming. It is not about 40 lines of code, it is about a basic programming model that allows us to understand and create user interfaces irrespective of how complex or large it is. I…
Actually, I wonder if there's something out there that has all the declarative state-to-DOM manipulation goodness, but does this at build time.
React is a runtime that works on the client, and its compile-time stuff is just syntax sugar (JSX) and some minor optimizations. As I understand, this runtime is the complexity that some complain about. At least I perceive this as a downside.
If there's something that can, given a component definition, generate those sets of add/update/remove functions and appropriate calls on state updates (preferably, as human-readable as possible) - I think that would be interesting to see and compare.
(I hope no one normally dynamically mutates their components at runtime?)
Re: An experienced Javascript developer’s account of learning React
#149I don't think the `className` argument sticks. `class` is reserved so you can't use it. It's annoying but not a difficult concept The other points are valid though. Mobx/Redux seems like a solution for big applications, but what's the alternative for small-to-medium React applications that still need to store state? I agree I had issues following the snippets (and for one snippet I would definitely have to check MDN…
> what's the alternative for small-to-medium React applications that still need to store state? I've found that with small React apps, you normally organise each component to be responsible for handling its own state. If you need a global shared state but your app isn't large enough for Redux then lots of people pass callbacks down to child components as parameters. True story.
Yes, that's what I do. Managing the global state in the main component, setting up functions to change the state via the update helper [1] and pass these functions down to the dumb components.
Re: An experienced Javascript developer’s account of learning React
#150Earlier quoted context omitted.
> If you consider 40LOC complex I don't understand why you work as a dev. Goodness, your snark that questions the parent's competence is not only unwarranted, it is based on an incomplete understanding of the value of abstractions in programming. It is not about 40 lines of code, it is about a basic programming model that allows us to understand and create user interfaces irrespective of how complex or large it is. I…
Actually, I wonder if there's something out there that has all the declarative state-to-DOM manipulation goodness, but does this at build time. React is a runtime that works on the client, and its compile-time stuff is just syntax sugar (JSX) and some minor optimizations. As I understand, this runtime is the complexity that some complain about. At least I perceive this as a downside. If there's something that can, gi…
https://svelte.technology/ is what you're looking for.
I haven't ever used it because I find React quite adequate. I share your concern about the complex runtime layer that React introduces, and it is getting even more complex with the introduction of Fiber.
However, the test of an abstraction is whether it leaks undesirably, and whether it lets you escape to the lower layers when you need to. React scores well on both counts.
So while the implementation might be complex and will get even more elaborate over time, the abstraction is as water-tight as I can hope. In that case complex implementations with better performance might even be a good thing.
Also, I strolled through the React codebase in its early days and found it eminently understandable. So if it ever comes to it, I'm confident I can contribute a patch for the things I need with enough time and effort.