JJinuxLand

What do WebASM, Reason, Dart, Rust, and Go all have in common? They're all trying to make the web faster. However, they do it in different ways.WebASM's approach is obvious. Take high performance code written in C and C++. Find a way to run it safely in the browser.Dart's initial approach was different. In the short term, Dart was meant to be compiled to JavaScript that would be faster than the JavaScript that you could write by hand. To a small degree, it succeeded. In the long term, the goal was to integrate the Dart VM into browsers. Unfortunately, this vision failed, and they gave up.Reason's approach is a combination of the above two approaches. In the short term, it can be compiled to JavaScript. In the long term, the hope is to use the OCaml-based version of Reason, and run it in the browser using WebASM. This is pretty forward thinking--which you might expect from Jordan Walke, the author of Reason.Go is a language aimed at replacing server-side C++. However, t…

I paid $200 to see all the O'Reilly Fluent Keynotes. These are my notes:@FluentConf #FluentConfOne of the speakers just lost his wife right before the conference. He has 7 kids. They setup a GoFundMe page for him.There was a really gorgeous wall that went across the whole stage that was a projection screen.The auditorium was only about 1/3 full, although it was very large. In general, the entire event felt extremely large, but fairly empty.All the sessions are being recorded and will be available via Safari. If you went to the conference, you get access to Safari for free for 90 days.Fixing the JavaScript Time ZonesMaggie Pint, @maggiepint, from Microsoft, a maintainer of moment.js.She's a date and time specialist.Moment gets about a million downloads a month. It's in practically everything.She was invited to work on Moment. She went to their issue tracker and looked for label:Up-For-Grabs in order to get started.She found something fundamentally broken and suggested a fix…

These are my notes from Apollo Day:Opening TalkMatt.There are about 100 people at the conference.summit.graphql.com is coming November 6-8, 2018 in San Francisco.Proof of concept -> initial production use -> principle production use -> company-wide standardization.We no longer just have a single backend talking to a frontend. We have multiple services now. We're writing for a lot of platforms these days--not just web and mobile. How do we connect all the backend services to the different frontends?Instead of defining specific APIs for each backend, use GraphQL for the backend to describe the data it has and the frontend to describe what the frontend whats. Apollo is in the middle. It's the implementation. Apollo is the tooling that extends across the entire stack. Apollo is about tooling, workflow, and integration.Schema-centric development is the anchor between the frontend and the backend teams.GraphQL Playground is a UI to explore a GraphQL schema.The tooling helps…

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…