JavaScript Fatigue

[SkinnyGeek1010]

I just want to mention a few things to newcomers to programming and JavaScript. It may seem like everyone is telling you to use X and Y or your app will burn into a pile of ashes. JS is maturing (finally!) and our apps are going from static pages with JS sprinkles to logic heavy apps, more similar to mobile apps than wikipedia.

However, I believe that it’s really important to learn and feel the pain before using some of these libraries. Otherwise it’s just overwhelming and doesn’t make sense as to why they’re doing X in the first place. You’ll end up wasting a lot of time that could be used to build cool things!

It’s incredibly hard to learn about building a maintainable app before you make spaghetti code and feel the pains from it. If something works, stick with it and most importantly keep an ear open for when these shiny things may help you. You just want to know enough about it so that you know what tools you have in your tool chest.

It’s more important to build a great product than to fret about making perfect stack decisions.

Examples with shiny tools (anecdotal but potentially useful, feel free to stop reading here )

##react

I’ve used Meteor since 0.4 and have loved using Blaze. Until I had 2 years worth of cruft from rapidly changing and removing features. With two developers and no standard you were never sure what a template/script was doing. Lots of find searches to see where Session was set and plenty of debuggers with Iron Router re-runs.

You end up getting really good at Blazes quirks but they never seem to vanish. Even with Flow Router and template variables it’s tough to keep things straight. Templates don’t compose well so having a 150 line template is not uncommon.

It’s also hard to tell if removing a thing will break another thing in a very certain context… until user’s email you about it.

After watching Pete Hunt use React in a Meteor app I couldn’t fathom why anyone would want to use all of that gobbly gook in their app. Blaze was clean! (well I thought then at least, the HTML was clean but not its JS).

Then I had to build a mobile app. React Native just came out so I subscribed to Egghead and in a weekend built my first RN iOS app! Compared to Objective-C the View and Text tags were much easier than Cocoa.

Then after some hacking (before the MDG magic sauce!) I dropped React into a fresh Meteor app and got started with a todo app right away. There was very little change from ReactNative except for using div instead of View. Tinkering with this taught me enough to keep my ears open when problems came down the road.

Later when having more issues with a Blaze app, I added React and changed a very small section while leaving the rest. I noticed that very little of the React code was buggy and gradually more and more got replaced (as features got added/updated/debugged).

In retrospect, the main benefit is a strict flow of data, declarative data, and a cohesive bond between templates and template logic. You could build a ‘widget’ without any context of the outside world which meant you could keep the entire flow of the widget in your head at once. Not easy with Blaze.

Takeaways… if you enjoy Blaze, great! Use it and build something cool. If you have spare time and would enjoy it, learn React (or Angular but that takes more time) so that you know what tools you can bring out in the future.

###Flux I started building a React Native app and was *very confused* with flux. I just ignored it and got to work using good 'old `this.setState`. It served me well for quite a while. Then it started getting confusing when editing/bugfixing. Then I recalled flux helped with this and only then dove into it. This time things made sense as I had more context. I *gradually* folded it into the app with new features and when I was debugging/changing old modules. I didn't have the time or $$ to stop building to swap it out.

With a Meteor context, use getMeteorData until it stops working for you. Local UI state (not database data) can be stored in a component with this.setState or it can be stored globally with Session.set("react:posts:fooIsHidden").

When your app gets to a point where you’re not sure where data is coming from or how the data got changed… start reading up on Redux (vanilla flux is too verbose).

###GraphQL

I’ve maintained a few APIs in my Meteor app for other things to consume and it’s always been a huge hassle. It starts off very simple and as things change, it gets hard. Maintaining V1/V2/V3 versions is very verbose and hard to change. REST makes things hard because you typically can’t get all your data with one request, unless you’re making custom endpoints. Sending just the fields you need makes things very complex on top of all of this but is required for mobile.

GraphQL looks complex at first but once you wrap your head around it, it’s simpler than making a REST API and fixes all of the above issues (and more).

In a Meteor context if you’ve struggled with sending multiple collections to the client or had to drop down to the complex low-level publish API, then GraphQL can help you out. If you have had to fetch non-reactive data then GraphQL can help you out in spades… Currently you need to use Meteor Methods to return data (like a REST custom endpoint).

GraphQL is main made up of schemas similar to Simple Schema. These are composed together to fetch and update data in a safe way. It also gives you autofill tooling to help build queries (note, in the future GraphQL will have optional types for rapid prototyping).

Again, if you’re not having pains don’t worry about it (well unless you like learning/tinkering on the weekend, then go for it!).

[SkinnyGeek1010]

Also worth mentioning… I don’t choose the FB tools because they’re trendy… i’ve compared others but these just seem to click with me.

I looked a Falcor vs GraphQL and the latter just clicked with me more. They both solve the same problem.

I’ve tried Angular 1.3 and it doesn’t jive well with me. I even built a prod. Ionic app to give it a fair shot. I couldn’t even tick a checkbox the regular web standards way and that was the last straw

I’ve tried Ember in the Backbone days but it’s too imperative for my taste. It’s also a full solution that doesn’t seem to play well with non REST data.

Om Next is probably the ‘best’ technology for a view layer IMHO, but I don’t want to write Lisp.

Elm solves the speed and declarative issues as well but isn’t really quite there for me. There’s also a language change so that’s more overhead.

Vue seems to be like a better Blaze but moves a lot of logic or non-html stuff to the template. I haven’t had the need to try this out past a hello world spike. It doesn’t seem to bring in any architecture patterns which is what I was missing in Blaze.

[ffxsam]

Fatigue is right! I’ve spent the past couple days just pulling my hair out over deciding upon architecture.

I determined (for myself, of course) that I have no need for Redux. Redux seems useful for people who are outside the Meteor ecosystem and don’t have handy things like ReactiveDict and MiniMongo. We have so many options to track state. The last thing I want to do is add more things to my stack; I’d like to keep it as clean and simple as possible.

I’m wondering what kinds of issues you ran into before using Redux that you felt ReactiveDict or React state couldn’t handle?

Everything else I totally agree with. Angular is overrated IMO, I felt it was too difficult to get simple stuff done. I gave it a good try (twice).

Lots of frameworks out there, but at the same time, lots of distractions and noise. I’m planning on investing my time in Meteor + React. But I will keep my ear open for new things, like you said. Meteor was once one of those new shiny things, after all.

[SkinnyGeek1010]

I determined (for myself, of course) that I have no need for Redux. Redux seems useful for people who are outside the Meteor ecosystem and don’t have handy things like ReactiveDict and MiniMongo. We have so many options to track state. The last thing I want to do is add more things to my stack; I’d like to keep it as clean and simple as possible.

I totally agree. I first used it in React Native which had 0 options for reactively sharing state across siblings/parents.

Also putting state in the top ‘page’ component and passing it down as props works for about 3 layers… then it takes a long time to find out where it’s coming from… at least it’s always ‘up’ but can be tedious.

Redux itself is interesting. If you are very comfy with flux and functional programming it’s easy to pickup. However, so many examples have ‘clever code’ using terse ES6 and solve the 2% cases with complex middlewares and ‘redux accessories’.

I started with Reflux (note the f) first because of it’s terse magic but then moved to Redux after good guides came out and by then had more ‘functional’ experience. I was thoroughly perplexed with it before I understood flux (mainly because I didn’t need it).

It sounds like a Reactive Dict and getMeteorData will get the job done.
Keep Calm and Keep Shipping!

[ffxsam]

Also putting state in the top ‘page’ component and passing it down as props works for about 3 layers… then it takes a long time to find out where it’s coming from… at least it’s always ‘up’ but can be tedious.

This is what I was confused about for too long. I thought “hey, instead of passing callbacks down via props X levels, I can just have the great-great-grandchild component call dispatch.” But I know many React devs are recommending the container approach where the container handles all state/actions and its children are stateless dummies in charge of rendering only. This makes sense: it keeps the stateless components very reusable, and if you run into any bugs in your logic, you know it’s in the container so you can track it down quickly.

So if it’s recommended to use that methodology even with Redux, then I didn’t see a point to using it anymore. And actually, after spending so many hours looking at Redux, Mantra, etc, I felt the hassle of passing props a couple levels down was a lot less of a headache and time investment for me.

[SkinnyGeek1010]

Bingo. The most important thing is tool X should make your life easier

The case where Redux was a real life saver was a form that made healthcare.gov look simple and had hundreds of inputs, several hidden/show states, etc… and passing props was too much. Also figuring out what component had what state was hard. Having one state tree in this case was amazing.

However, another app i’m making for another client is the complete opposite… Redux would be a burden, even though I fully understand it. It’s getting a simple ‘PostsContainer’ with getMeteorData for DB state. Done!

Even in between (which is were most apps are I would guess), going one way or the won’t build up too much technical debt.

[churcho]

[quote=“SkinnyGeek1010, post:4, topic:16539”]
I totally agree. [/quote]

I am guessing that you mean usage is dependent on context and application type. I am just going through the tutorials after realizing I ‘need’ it to better use React Components. How can we replicate the functionalities within Meteor using getMeteorData()?

Also putting state in the top ‘page’ component and passing it down as props works for about 3 layers… then it takes a long time to find out where it’s coming from… at least it’s always ‘up’ but can be tedious.

Do you have an example of how one can achieve what redux offers within Meteor? React is turning out to be quite a headache… going by the boilerplate and extra concepts to learn.

[workman]

I couldn’t even tick a checkbox the regular web standards way and that was the last straw

Funny that you say that, I’ve just started with react and I’m enjoying it, however one of the things I just noticed and was super annoyed by was the fact that React doesn’t listen to events how you would expect. Assuming you have this (onChange listens to onInput events, or so the React documentation says so):
<input id="my-input" type="text" onChange={this._onChange} />
if you then run jQuery to trigger an event like so:
$('#my-input').val('new-value').trigger('input');
React never runs it’s event handler. Not sure how or why, but I eventually found out you need to do this within React’s TestUtils, which doesn’t get loaded in production! Not a big deal for me, as I only need this behaviour during testing.

[greblak]

I started web development with PHP4. Relatively static pages and always that awful reload upon data change.
I fiddled with Angular and Grails shiver…
Even Google App Engine and Django.
There are so many paradigms and frameworks you could go mental.

I’m a huge fan of having a huge toolbox and know your tools pretty decent over choosing to always use a screwdriver. Even when hammering in nails. It’s possible, but so much harder.
With Javascript and the 14 package managers, 42 front-end frameworks, 13 backend communcation tools, 5 data flow libraries, 143758275 template engines and 143 backend systems all trying to talk together it’s a clusterpuck… The fatigue is real. Being a web developer able to get any web developing job now requires more knowledge than a real-time systems developer needs…

Now as I said, I’m all pro-choice but this is starting to become quite ridiculous
I tried Blaze. Cool but ended up with some spaghetti whenever I needed something more fancy than autoform. autoFlush and rendered will be the death of me…
React seems pretty sweet. More control. Originally opposed to putting design in logic, but it’s better than logic in design…
Never liked Angular. Too much ng- everywhere.

Meteor finally shaves the whole backend and backend communcation bit off. More time for reactive frontend. Thank you! But with 1.3 we have an issue coming up. Noone will use react-packages on atmosphere now that we have npm-modules. Why would we? They would override each other and double-load react-runtime.
So now we end up with using 2 package managers for one project by just using react.

One of the things I really like about Meteor is the exceptionally simple package manager.
Now I gotta start thinking like I’m using C/C++ and #include to ensure I get access to the code I need. Sure, it gives me load order control and less global namespace clutter.

Besides ReactiveVar/Dict, minimongo/DDP and Meteor methods. What’s left of Meteor when using React?
I feel MDG is slowly outsourcing pieces of Meteor until we’re finally left with nothing but a boilerplate and “best practices”

Consider the intro for newbies with react in 1.3. It seems to be quite an ordeal compared to 1.1 and Blaze!

[sashko]

Consider the intro for newbies with react in 1.3. It seems to be quite an ordeal compared to 1.1 and Blaze!

I think this is one difference between official Meteor content, which takes great care to avoid “ordeals”, and content from the community, which often espouses cutting-edge technology but can involve more work. Hopefully getting started with React and Meteor in 1.3 is going to be quite simple, and we’ll update the tutorial on Meteor.com accordingly.

[greblak]

The problem isn’t the initial start. The problem appears when they have to transition because they have to do X which is not in the meteor tutorial, likely stating “use atmosphere package react”
.
Now they have to unload react from .meteor/packages and use npm to load react. Suddenly they need to add import everywhere. Stuff like this will turn newbies off from Meteor real fast I fear!

Edit: Typo

[MellowProgrammer]

I’ll be looking into GraphQL soon.

Vue doesn’t make any assumptions about your architecture, so you can use a flux implementation like Redux with it or just keep the state/logic coupled with your components(meh).

Vue also has it’s own flux-like implementation if you use Vuex, to manage state. It’s very helpful and keeps logic out of your components other than the need to call actions.

http://vuex.vuejs.org/en/data-flow.html

[SkinnyGeek1010]

How can we replicate the functionalities within Meteor using getMeteorData()?

So if you want to replicate Redux exactly it’s easiest to just use Redux. However, you could make one Reactive-Dict, save it to a global like appState, and then use getMeteorData to watch any keys.

You can either set the data the normal way, or if you’d like you could create a file called ‘actions’, create a normal function called createPost and then from your view, pass in form data to createPost, which takes all of the mutation logic out of the view and moves it into a single place actions. Ideally any time you ‘change’ something on the client it should happen in an action.

Do you have an example of how one can achieve what redux offers within Meteor?

This example is really good. You might even want to try this out of Meteor to force yourself to not do it the ‘meteor way’ and then once you understand it, add any Meteor features in that you’d like

Composition vs Inheritance - React

[SkinnyGeek1010]

Funny that you say that, I’ve just started with react and I’m enjoying it, however one of the things I just noticed and was super annoyed by was the fact that React doesn’t listen to events how you would expect. Assuming you have this (onChange listens to onInput events, or so the React documentation says so):<input id=“my-input” type=“text” onChange={this._onChange} />if you then run jQuery to trigger an event like so:$(’#my-input’).val(‘new-value’).trigger(‘input’);

It sounds like there’s a larger paradigm problem going on. You really shouldn’t need to trigger an input with jQuery like that. If you could provide more info of the use case i’d be happy to check it out.

When I do forms in React I make them very ‘dumb’ and basically only use props to pre-fill data if needed. Otherwise I just let the user input text as normal and onSubmit i’ll use jQuery or vanilla JS to parse the form, return all data as an object like {name: "Adam", username: "SkinnyGeek1010"} and then that data gets sent somewhere.

Some people like to have controlled forms which force the value with this.state and it ends up being overly complicated for 99% of cases.

Basically my forms are parsed the same as when I use Blaze.

[SkinnyGeek1010]

Now they have to unload react from .meteor/packages and use npm to load react. Suddenly they need to add import everywhere. Stuff like this will turn newbies off from Meteor real fast I fear!

Hopefully the double loading of React will be resolved somehow. IMHO if people build good packages it should be agnostic to REST/Firebase/Meteor data.

JavaScript users will have to decide if they want the 1995 era of JavaScript with globals or like every other real language… use modules and module imports. This is more of a JS problem than Meteor problem IMHO.

[churcho]

This example is really good. You might even want to try this out of Meteor to force yourself to not do it the ‘meteor way’ and then once you understand it, add any Meteor features in that you’d like

Thanks for the reply, Adam also has a very good post on dump and smart components somewhere. Let me rephrase my question, under what circumstances would it make sense to use redux and do you have a repo that shows non redux with a comparison to redux way to show the benefits?

It feels like we are chasing cutting edge instead of focusing on productivity. By the way your Mediator pattern tutorial back in the days got me hooked on Meteor

[SkinnyGeek1010]

Haha nice, thanks!

The only non-flux react app i have is: http://react-ive.meteor.com/ and ive wanted to make a flux branch but never did. I think it comes down to complexity. If not using flux seems ok then I would run with that. If the possible states your app could be in seems complex, Redux is more attractive.

At any rate getting business logic out of the UI and into one place is a win!

[tgoldenberg]

You shouldn’t need jQuery with React. The whole point of the Virtual Dom is to be able to reference things without the need of $. throw a ref on an element ref='input' and then reference it within the component as this.refs.input. As simple as that

[efrancis]

However, I believe that it’s really important to learn and feel the pain before using some of these libraries. Otherwise it’s just overwhelming and doesn’t make sense as to why they’re doing X in the first place. You’ll end up wasting a lot of time that could be used to build cool things!

this x1000.

I always see newer programmers jumping right into Angular or React or Ember and they end up plugging together pieces until something works without ever knowing why they’re doing it or how the underlying code works at all.

I really recommend that anyone new go pick up and read Programming JavaScript Applications, it’s IMO the best intro to JavaScript and is available for free online right now. JavaScript: The Good Parts is another must read. So many ppl hop online and try to learn JS through random forum posts and blogs, just go read a book, it’ll help you a lot more.

Also, trying to build a small application from scratch without any framework is something everyone should try. Do it for a week and the advantages and reasons for Angular/React/FrameworkXYZ will become a lot more clear.

[churcho]

Another good read is Eloquent Javascript. Helped me quite a lot.