loading...
Cover image for React and the nonsense.

React and the nonsense.

jorgecc profile image Jorge Castro ・2 min read

React

In modern javascript, there are 3 ways to write the same code, and all those methods are not even 100% compatible.

Method 1 functions

function Welcome(props) {
  return <h1>Hello, {props.name}</h1>;
}

Pro:

  • it is compatible

Cons:

  • it could turn into a mess in no time.
  • But where I initialize the states or lifecycle?.
  • "this" bug.

Method 2 ES2015 OOP

class Welcome extends React.Component {
  constructor(props) {
    super(props);
  }
  render() {
    return <h1>Hello, {this.props.name}</h1>;
  }
}

Pro:

  • It's OOP
  • It's scalable
  • It allows managing the lifecycle of the component.

Cons:

  • Ha Ha, no -REDUX

Double arrow function


Not Sparrow but this one "=>"

Double arrow with OOP

Let's check this code.

class Welcome extends React.Component {
  constructor(props) {
    super(props);
    this.someMethod= this.change.bind(this);
  }
  someMethod() {
      // whe use this  
  }
}

It could be written as

class Welcome extends React.Component {
  constructor(props) {
    super(props);
    //this.someMethod= this.change.bind(this); we don't need this one anymore
  }
  someMethod=>() {
      // whe use this  
  }
}

So, it makes sense to always use double-arrow. Always.

And REDUX

REDUX preaches that it is technology agnostic but it is not because we will also use react-redux and it is not technology-agnostic.

Long story short, in Redux we will call this code:

// ....
export default connect()(Welcome)

If Welcome is an ES6 class, this code will crash. After all, "connect" expects a function, not a class. We could write some nasty wrapper for our class (a wrapper method) but it is not advisable. So, if we want redux (and we want it), then our classes must go. Something about higher-order-component (what is that anyway? Is it like high-order-elves? elves are cool btw).

Googling I found this code:

class Welcome extends React.Component {
  render() {
    return <h1>Hello, {this.props.name}</h1>;
  }
}

export default connect(({ stateStuff }) => ({ stateStuff }))(Welcome); 

I don't know what it really does but sometimes, working on React is putting faith in some library (and hoping that it works. And, how it works? nobody cares).

So our methods could be implemented as:

function Welcome(props) {
  return <h1>Hello, {props.name}</h1>;
}

But hey, we should use double-arrow, so

const Welcome=(props)=> {
  return <h1>Hello, {props.name}</h1>;
}

Pro:

  • it works with redux (react-redux)
  • It avoids the "this" bug (if any), we are not using class so it is not required but who knows really. So double arrow is our safe bet.

Cons:

  • No constructor and it could be tricky to use states but Redux replace States (not really)
  • If you are worked with other languages (especially a language with OOP), you could ask it:


We kill OOP and SRP in a single shot.

And the answer is FUNCTIONAL PROGRAMMING. sigh And I have not even talked about to define an anonymous function inside the template, ahem JSX code.

tl/dr

  • Classes = nope.
  • React states = no.
  • Normal functions = none.
  • Use arrow function and react-redux (also react-route but it just works).

Posted on by:

jorgecc profile

Jorge Castro

@jorgecc

You are free to believe in whatever you want to, me too. So, stop preaching your religion, politics, or belief. Do you have facts? Then I will listen. Do you have a personal belief? Sorry but no.

Discussion

markdown guide
 

I can see you are frustrated. I'm sorry that you are going through hard times adapting to a new paradigm.

The language that you use can trigger other people. Some people like functional programming (doubtful idea to connect own identity to a programming paradigm, but that not my business) and they can be offended.

Maybe you can tell your story in a softer tone. Like: I tried approach A, but I got confused by this. I tried approach B, I got confused by the need of binding, etc. This way other people can learn easier that you learned hard way. As well maybe somebody would want to help you and explain alternative approaches (and why you would want to do this). Win-win?

 

a) It's not a new paradigm, it's an old one.

b) People get triggered by everything. Also, I'm talking about technique, not believes or religion. You can shot me some facts and I can say "oh, I didn't know about it". ALSO, I don't clickbait some topic, I put cases and examples but you already know that.

And my conclusion is still here: => for everything, OOP nope, and function nope.

Now, about what I said. it is MY (and YOU) problem. SRP.

Let's say we have a team of three, one connects to the database, other does the visual layer and the last one joins altogether.

I know that reactjs is not about the database, so the first one is out of this image.

But reactjs is about visual. Can I integrate a team member that knows about html but it's clueless about programming?. Not with react, because it mixes JSX and codes all in the same package, it breaks SRP and it affects the people.

Now, about it, mileage ALWAYS can vary and it depends on the project and team. So for every problem, there is a better solution. Let's say our team is only javascript developers, hence it makes sense to program with it. However...

 

a) It's not a new paradigm, it's an old one.

I mean new for you paradigm. Sorry for confusion.

Also, I'm talking about technique, not believes or religion.

Can you define functional and OOP paradigm then? So we can start constructive argument (I don't provide mines, so we would work on your grounds).

I mean new for you paradigm. Sorry for confusion.

No, it's not.

And what's the difference between OOP and functional. Simple. With OOP we create a space of memory (stack) using a definition of code (classes) to do our operations (states and methods), while with Functional Programmer, we passed a function to another function as an argument (some sort of heap).

Thanks for definitions. I'm not quite sure about stack/heap distinction (does it really matter how memory organised?), but otherwise definitions are clear πŸ‘Œ.

But functions in functional programming can allocate memory as well, right? To do this we use closures ("A closure, the opposite of a combinator, is a function that makes use of free variables in its definition. It 'closes' around some portion of its environment. for example"). Example:

const a = () => {
  const b = 0
  return () => {
    return b + 1
  }
}

Do you agree? (I'm doing this step by step, to make sure we are on the same page)

 

If people are offended because someone criticizes some programming conventions, I'd say it's them who have a problem and should do something about their attitude, not the author. Nowadays people get way too easily offended over things no sane person shall ever feel offended about. Catering to them is bound to create problems, and an environment where people are afraid of speaking against anything at all for fear of offending someone out there.

 

It's okay to criticise for sure, but a bit softer tone would be nice. Don't you think?

What I suggested is the same critics but in different form. Instead of

  • "this doesn't work, functional programming to blame"
  • "this doesn't work as I expected and I got frustrated. This is what I got used to in OOP, I don't understand why this is done this way in FP"

Critique is the same, emotion is different. Instead of "😠, 😑, 🀬" it can be "πŸ€”, πŸ˜–, 😩".

And here is what happens next:

  • this 😠, 😑, 🀬 creates more of those in comments 😑😑😑😑😑(pushback, angry)
  • this πŸ€”, πŸ˜–, 😩 creates more of those in comments πŸ˜₯πŸ€—(compassion), ☝(advice), πŸ€”(maybe current approach is wrong and we need to change it)

It's about technology, not people, SHEESH.

I can't really tell if you agree or not.

 
 

Javascript uses several features that are Functional Programming.

However, other languages are pure-functional (LISP for example). If Javascript is or not functional, then it is only rhetoric. The true fact, React encourages to use of functional techniques and features but also encourages to use OOP (official website) but mixing both techniques don't work and it is a big trap.

 

I was referring to Elm, which transpiles into JavaScript.

I was not referring to JavaScript as a functional programming language.

Anyone who lauds JavaScript, or C++, or Swift, or Python, or Lisp as functional programming languages should spend a little time with an actual functional programming language like Elm, Haskell, F#, or OCaml.

For those who like Lisp, Clojure is a blend of Lisp and FP. For those who are on the JVM platform, Scala is a blend of OOP and FP. I'm familiar with Lisp, and I'd categorize it as a programmer's programming language that has a bona file REPL (unlike languages like, say, Python that some claim to have a REPL). Yes, you can (awkwardly) do functional programming in Lisp, much like how one can (awkwardly) do OOP in C. But doing FP in a FP language works a lot better, just as doing OOP in an OOP language works a lot better.

 

You may be happy to know that you misinterpreted the error you got back from react-redux. The error is there because connect expects a function as the first argument of the first invocation, not the second, where you passed in the Welcome class. It is completely fine to use classes with Redux. Also if you don't want to pass in that helper function, if you just pass in null, it should work fine. Hopefully that clears up your misunderstanding!

 

Not having worked a lot with react/redux but when I saw that connect was giving op an error for a second I started questioning if I had ever learned it properly. Apparently I had and of course it's perfectly legal to use redux connect with react class components. Thanks for reassuring me I am not going senile. :)

 

No problem. It's too bad that the whole premise of this article was built around a pretty significant misunderstanding. Oh well! I'm happy to give you pointers if you have questions with react or redux at all!

Yes, can you enlight me about what I missed?

I'm not going to get into it with you, because you're obviously pretty passionate about this topic, and I don't believe we would have any kind of a reasonable discussion. If you read my original comment to you, not this follow-up comment, you'll see where your premise is based on a misunderstanding of an error you saw.

sheesh.

It is the point, we have a team working on react (it's not my project, lucky for me) and I found that it uses different styles (and it is horrible, zero teamwork). So, in case of doubt, I stick with the standard, and most of my examples are from the official documentation. So, if you ask what is the problem with react, IT'S NOT ME (you could blame the documentation & community, proof? official websites). Well, about the project, I found that (excluding some guys that added some duct-taped some libraries to the project), they follow the standard but there is not a single standard, react in one style, redux in other and everything is really messy, ergo my post. So, are they wrong? well, technically no, but as organization yes. And shocking, I found that it is the way of react. It is so wrong.

Now, Am I passionated?, always! but I can't find much value on react. It's popular but that's it. Why?. I pointed at a few simple examples and it fails. Of course, React is a nightmare with a form, a simple form.

Alright, that would be frustrating. But to me, this is a strength of React. I like that it isn't opinionated, but that you get to choose your style, you get to choose how you build your app. The potential pitfall is that teams that don't set standards -like all data from our API should be managed by redux - will definitely have a hard time with it.

But don't blame react for that. That's an organizational problem on the team. They need to decide how everyone is going to code the app.

Now, if you don't like libraries that let you make those decisions, if you want your Framework to be very opinionated, and tell you the one way everything should be done, that's totally fine. But don't write up a post on an unopinionated framework saying how bad it is, just because it's unopinionated.

Finally, what I was referring to was your example of this:

export default connect()(Welcome);

where Welcome is a functional component. You said it threw an error, and therefore you assumed that connect doesn't work with functional components. That's wrong.

It threw an error because the first invocation can't be empty. It works with a functional just fine if you do this:

export default connect(null, {})(Welcome);

So that's where your premise that "redux didn't with with functional components" was based off of a bad assumption, and a misinterpretation of an error.

Coffeescript is not dead.
The people using it are just not busy publishing articles.

I've built my DSL/Webframework over top of Mithril which allows me to rapidly build web-applications the likes you've never seen before.

I don't deal with "components", or "redux", I have a concise DSL which takes care of every possible use case. How do I know this? I've built at least 20 web-apps in this framework of various nature.

Infact my DSL started using Angular 1. When I wanted to move to Mithril I just changed the engine. I could probably write my DSL to move between Mithril and React.

$controller 'playlists/index', class extends List
  pull: true
  popups: true
  search: 'location'
  paginate: true
  attrs:=>
    attrs =
      filter: @$.filter.join(',')
  constructor:->
    @$.filter = ['youtube']
    super
    @$export 'reindex',
             'edit'
    @$.playlists_new =
      model : $model('Playlist')
      pop   : m.prop(false)
      title : m.prop('')
    @$.playlists_edit =
      model : $model('Playlist')
      pop   : m.prop(false)
      title : m.prop('')
  headers:(xhr)=>
    @$.paginate.pagination = JSON.parse(xhr.getResponseHeader('X-Pagination'))
    @$.youtube_count = parseInt xhr.getResponseHeader('X-YoutubeCount')
    xhr.responseText
  edit:(ev,model)=>
    ev.preventDefault()
    ev.stopPropagation()
    @$.pop.edit(model)
    return false
$view 'playlists/index', class
  layout: 'admin'
  heading:=>
    $$.page_heading null,
      paginate: @$.paginate
      search: @$.search
      new: @$.pop.new(),
      content:=>
        m '.toggle',
          m 'a.tab', config: m.route, href: '/admin/playlists'     , 'Playlists'
          m 'a.tab', config: m.route, href: '/admin/youtube_videos', 'Youtube Import'
  table:=>
    $$.data_table @$.playlists, 'playlists',
      columns:
        id:
          label: 'ID'
        name: true
        lecture:
          label: "Lecture?"
          content:(model)=>
            if model.lecture
              m '.fa.fa-check'
        lecture:
          label: "Latext?"
          content:(model)=>
            if model.has_latex
              m '.fa.fa-check'
        youtube:
          label: "Youtube Code"
        created:
          label: "Created"
        actions:=>
          onedit = (e)=>
            $stop(e)
            @$.pop.edit(model)()
            return false
          ondestroy = (e)=>
            $stop(e)
            @$.destroy(model)
            return false
          m '.fa.fa-trash-o', onclick: ondestroy
          m '.fa.fa-pencil' , onclick: onedit
  render:=>
    m '.content_wrap',
      $popup 'playlists/new', @$
      $popup 'playlists/edit', @$

      @heading()
      m '.content',
        @table()

Coffeescript is amazing with Mithril because it allows me to use their hypertext format. No garbage JSX. It wasn't that weird to adopt, just felt like writing haml.

React + Redux is garbage. So many tutorials have been produced and so many jumped onboard since it's endorsed by Facebook.

The author of this article is not crazy. React and Redux are awful tools. They don't re

 

Why the "FUNCTIONAL PROGRAMMING. sigh"?
As someone loving the functional programming I'm really interested in why such "hostility" toward it? (Or maybe I misunderstood?)

 

Because:

https://i.imgflip.com/33jbl2.jpg

Mainly SRP and it hurts.

ps: btw functional programming is nothing new.

 

Torally agree with functional programming being nothing new. But yet again is there anythibg in computer science that is really brand new? We do new with old stuff essentially, improving (or not) at each iteration. Well at least that's my perception of things so far.

 

You can use @connect decorator to apply redux bindings to classes if you wish - you're not limited to functions with redux. Still, I personally find functional components more compact and easier to maintain. I mostly use them as "dumb" components that care about UI only, and if I need to do some state management, it's usually a good task for a @connect'ed class.

Is CoffeeScript 2 dead? (Where "dead" means "yeah, it's out, it produces ES6, but it isn't gaining much traction in the industry. Should have come out when TypeScript came out, but it came out too late.")

 

Redux seems like a nonsense to me. People are using it just because they see everyone else doing so. Friend from my uni working at different firm asked me once "Wait you are not using some middleware (with Redux)? How are you then doing any back-end API calls?". Yeah, little part of me died that day.

 

Yes but I don't do the calls here. The use of reactjs, react-route, and react-redux (amongst 30 more technologies) its a classic stack.

Personally, I don't like Redux cause it's bloated but it is popular.

I got to do a big project in TypeScript 0.8, and I often looked longingly at CoffeeScript.
I liked that TypeScript brought ES6 features to ES3 and ES5. I like the static type checking.
But I admired CoffeeScript's succinctness and expressivity.

 

Classes in JS is not an OOP feature. It’s just a syntactic sugar for functions with prototype-based inheritance. Probably it’s the worst JS syntax as it confuses people.

I can see how you might think I fit the criteria but maybe you can be more respectful in your responses. I noticed you are nearly anonymous online. Maybe there is a good reason for this.

 

I thoroughly enjoyed reading this! Yes, the JS ecosystem is one big WTF at the moment. :)

My DSL is fully documented now. Its no different than learning any other tool.

Yo Neil,

I was ranting and quickly started to talk to this non-existent audience.
I absolutely agree with you.