JJinuxLand

I just upgraded mobx-react from 4.0.4 to 4.4.3. In theory, this should not have required any code changes. However, starting in mobx-react 4.1.2, there was something that tickled what I'm guessing is a hidden bug in Enzyme 3.3.0. We had a test that would purposely throw an exception in the render method of a React component. The test was written using shallow. Even once I had gotten the test to pass in mobx-react 4.1.2, it was somehow poisoning something unknown which caused about 0.5% of my other tests to fail. It was perfectly reproducible if I ran all the tests, but running any of them individually would not fail. It was quite baffling. My buddy Kevin figured out that moving from shallow to mount fixed the issue, inexplicably. It's a workaround, but we'll have to just live with it since I have no idea how to find the bug in Enzyme. Note, we're using React 15.6.2 and MobX 2.7.0.

I just finished upgrading mobx-react from 3.5.9 to 4.0.4. By far, the biggest change is that "this.props and this.state in React components are now observables as well". Of course, you can read about this, and all the other changes, in the CHANGELOG.

One thing that really made this upgrade hard is that there was an issue with react-css-modules that caused me to have to move to babel-plugin-ract-css-modules per my earlier blog post.

Because props are now observable, if you make changes to them in your tests, you should wrap those changes in runInAction.

Sometimes, I see test files that call mount() in beforeEach. Then, in individual tests, they try to futz with things which means they end up needing to call wrapper.update before making their assertions. It's easier to do some setup in beforeEach, do any specialized setup in the individual test, and then make some helper function called mountWrapper that you use in each test. That way, you don't mount until you'…

I recently found a bug in react-css-modules that prevented me from upgrading react-mobx which prevented us from upgrading to React 16. Then, I found out that react-css-modules is "no longer actively maintained". Hence, whether I wanted to or not, I was kind of forced into moving from react-css-modules to babel-plugin-react-css-modules. Doing the port is mostly straightforward. Once I switched libraries, the rest of the port was basically:
Get ESLint to pass now that react-css-modules is no longer available.Get babel-plugin-react-css-modules working with Less.Get my Karma tests to at least build.Get the Karma tests to pass.Test things thoroughly.Fight off merge conflicts from the rest of engineering every 10 minutes ;) There were a few things that resulted in difficult code changes. That's what the rest of this blog post is about. I don't think you can fix all of these things ahead of time. Just read through them and keep them in mind as you follow the approach above.…

As usual, you should check out the CHANGELOG. However, let me point out a few things specifically:

If you have something like: observable({ @computed get someProp() { ... } }); your code will work in 2.6.0, but in 2.7.0 reactions won't occur properly. Your tests will end up timing out. It needs to be: observable({ get someProp() { ... } }); Note, there's no deprecation warning or anything. Also note that this doesn't apply to situations where you're using a class. Those will continue working as before.

As of 2.6.2, toJS no longer recurses once it hits something that isn't observable. Hence, if you have an observable object with a non-observable array with observable objects in it, MobX will only convert the outer object "to JS". You'll need to call toJS again for the things inside the non-observable array. This can cause painful to debug errors.

This change was announced for 2.6.0, but it actually happened in 2.6.2 which means that upgr…

I spend a lot of my time refactoring code across a very large, legacy codebase at work. Often times, I'll do a search for something and work my way through the results over a period of days. Sometimes, something I see might lead me to do another search and a minor refactoring job which is part of the overall refactoring job. Hence, sometimes I end up with a "stack" of different searches which represents all the parts of the overall refactoring job. In each of these search results, it's important to not "lose my place" as I go down the list.

WebStorm / IntelliJ / PyCharm support this workflow really well:

Notice, I have multiple search tabs open at the same time (which is missing from VS Code). I can cross things off the list (which you can do in VS Code via deleting the item). And I don't lose my place in the list when I edit the code (another key benefit over VS Code).

NetBeans also lets you have multiple search result tabs at the same time.

It's …

I spend a lot of time futzing with editors and IDEs. To be honest, I'm pretty compulsive obsessive about the whole thing. I can watch YouTube videos for hours studying how each works and why people like them. One question that I really wanted to tackle is "Are there ways in which VS Code is actually better (i.e. more productive) than WebStorm, PyCharm, IntelliJ, etc."

I think this video Moving from WebStorm to VSCode does a pretty good job tackling this question, but I remain unconvinced.

I think there are three things I miss the most in VS Code compared to PyCharm, WebStorm, IntelliJ, etc.:

1. The Find window is much better in PyCharm. I can search for something in order to do a cross-project refactor. As I go through each entry, I don't lose my place in the find results, even if I have to edit the code for a few minutes. (Trying to do the same in VS Code is a fairly frustrating experience.) If I need to search for something else, I can save the results in a new…

Here are my notes from Chrome Dev Summit 2017:Here's the schedule.Here are the videos. KeynoteBen Galbraith and Dion Almaer, Director, Chrome Web Platform and Director, Developer Relations@bgalbs and @dalmaerThis was the best talk of the whole conference. They covered a lot of new stuff in a very short amount of time. This one talk is the talk that's the most worth watching.They plugged PWAs (Progressive Web Apps).Lots of browsers support Service Workers. It's still in development for Edge and WebKit, though.Workbox is a library they built for working with Service Workers. It's used by 70% of the sites using Service Workers.They plugged letsencrypt.org.64% of traffic is transmitted over HTTPS on Chrome on Android.They're going to start marking any form that isn't submitted over HTTPS as not secure.Use autofill completion hints to help out Chrome with autofill.They plugged PaymentRequest. It's a payment UI that is built into Chrome itself. It cuts down the tr…