- Not all features (e.g. most built in directives) work in JSX, and some 3rd party libs didn't work at all as JSX components.
- The JSX isn't a direct mapping to the object properties in `createElement`, which is how (almost?) every other flavor of JSX works. This means you don't just have to learn the the low-level `createElement` API, you also have to learn how that API maps to JSX. [1]
For example, you can't do `<div domProps={{ innerHTML: 'foobar' }} />`, which you might expect if you just read the `createElement` docs. Instead, you have to use `<div domPropsInnerHTML="foobar" />` (but note that not all `domProps` actually need the prefix [2]). Likewise, event handlers use an `onEvent` camel case convention that maps to the `on` property in `createElement`, which is kinda nice because that's how you add event handlers in other JSX flavors. However, it also means that if a Vue component accepts an `onSomething` prop, you actually have to do something like `propsOnSomething` [3] in JSX, because passing just `onSomething` would convert it to `on: { something: ... }` instead of `props: { onSomething: ... }`.
Overall, when I was trying to use JSX with Vue, it very much felt like a second-class feature, tacked on primarily (if not exclusively) to help convert people from React. However, Vue's flavor of JSX doesn't seem to appreciate that the simplicity of how React maps JSX to `React.createElement` is a large part of its brilliance.
In other words, I think that Vue's flavor of JSX introduces just enough magic to make it confusing. It sacrifices consistency for haphazard ergonomics, making the experience frustrating for someone used to JSX being just an XML-like alternative syntax for `createElement` (or `h` or `m`). I think Vue's JSX would be much better if it didn't try to do any magic, and just forced people to write stuff like `<button on={{ click: () => {} }} />` instead.
In the end, I gave up on using JSX with Vue, tried templates for a bit, didn't like them, and moved away from Vue altogether.
Caveat lector: Things might be a lot better now. I tried to read up a bit to see, but I didn't dig very deeply.
> 2. Paper and pen (the surfer example) also have technological constraints. It's a "2D" surface, width of line, etc.
This is true, but it's kind of true in the same way that walking and flying both have movement constraints. Flying certainly has limitations, but just like pen & paper give you more flexibility in composition than entering a string of characters, flying offers much more freedom of movement than walking.
> 4. What about non-alphabetic written languages?
Most (all?) current non-alphabetic orthographies are non-pictographic. While many characters for common words may have started that way, the majority of characters in these systems are nowadays not obvious pictorial representations of their meaning.
It's possible that this will eventually be the case with emoji, too, but currently it's not.
> It depends on language, in Japanese input methods a lot of emoji can be written exactly the same way you write rest words.
The SwiftKey keyboard on Android offers this feature. If you turn it on and type 'angry', for example, it offers both the word and the emoji as predictions.
It works pretty well for English, but I'm not sure how well it works for other languages SwiftKey supports.
I'm not sure about other countries, but in Zambia at least the malaria rates are not spread uniformly around the country [1]. If your family is in Lusaka, for example, both they and your daughter should be pretty safe, especially if they take precautions like sleeping under a net.
You probably already know this, but if your daughter shows any symptoms of malaria, make sure you tell the examining physician that she's just returned from an area that is known to have malaria. It's often one of the first things doctors test for here in Zambia, but if you live in an area without endemic malaria, they might not test for it at all.
> You probably already know this, but if your daughter shows any symptoms of malaria, make sure you tell the examining physician that she's just returned from an area that is known to have malaria. It's often one of the first things doctors test for here in Zambia, but if you live in an area without endemic malaria, they might not test for it at all.
Also, for the blood test, make sure she actually has a fever when the blood is drawn.
Malaria (in the initial stages) may have a fever that comes and goes. The test has much higher false negative rates if the blood sample is drawn when the patient does not have a fever.
Doctors in areas where malaria is endemic generally know this, but doctors elsewhere may not. If she has any signs of a fever for the next ~2 months, it's best to get a blood sample drawn right away. Malaria is much more treatable when detected early.
The short, unsatisfying answer is that using `class` is deprecated in React, and has been for a while.
For a longer answer, take a look at the discussion of issue #4433 on github [1], especially the following comment by spicyj [2]:
> [...] We're sticking with className and htmlFor for a couple of reasons:
> First, we tend to look at HTML properties (like el.className = ...) when possible, as opposed to attributes (like el.setAttribute('class', ...)). Attributes are always string-typed, while properties can have any JavaScript object value, which gives more flexibility in some circumstances. One example is the .classList property, which arguably is a better fit for the data model than .className is. React doesn't support classList right now, but it certainly could. Given that React's className behaves like the HTML property of the same name, it makes sense to keep that name.
> Another reason is more forward-thinking. In the future, idiomatic React may use object destructuring to pick apart this.props. The react-future repo shows one example of how this could work. Even in modern browsers, this wouldn't work with class and for which are keywords and can't appear as standalone identifiers even though they can appear as property names.
> Third, our thinking is that JSX's primary advantage is the symmetry of matching closing tags which make code easier to read, not the direct resemblance to HTML or XML. It's convenient to copy/paste HTML directly, but other minor differences (in self-closing tags, for example) make this a losing battle and we have a HTML to JSX converter to help you anyway. Finally, to translate HTML to idiomatic React code, a fair amount of work is usually involved in breaking up the markup into components that make sense, so changing class to className is only a small part of that anyway.
I might not be seeing this feature, but do you have any plans to add pre-built sets of cards?
I understand the purpose is to practice skills relevant to oneself, but it would be nice to have at least a set of basic cards for popular languages (JS, Ruby, Python, etc.), which users could then import and change up to suit their needs.
I think it would also be nice to have a couple demo cards that people could run through before signing up for an account.
Re having a complete pre-built set: I hope we don't have to do that, tbh -- making your own cards is a crucial part of the learning process. I do think we need to explain that better, though.
As for demo cards: Absolutely! We need a better onboarding process.
Did you try it out? How did you find the card creation process?
A couple of problems I remember having:
- Not all features (e.g. most built in directives) work in JSX, and some 3rd party libs didn't work at all as JSX components.
- The JSX isn't a direct mapping to the object properties in `createElement`, which is how (almost?) every other flavor of JSX works. This means you don't just have to learn the the low-level `createElement` API, you also have to learn how that API maps to JSX. [1]
For example, you can't do `<div domProps={{ innerHTML: 'foobar' }} />`, which you might expect if you just read the `createElement` docs. Instead, you have to use `<div domPropsInnerHTML="foobar" />` (but note that not all `domProps` actually need the prefix [2]). Likewise, event handlers use an `onEvent` camel case convention that maps to the `on` property in `createElement`, which is kinda nice because that's how you add event handlers in other JSX flavors. However, it also means that if a Vue component accepts an `onSomething` prop, you actually have to do something like `propsOnSomething` [3] in JSX, because passing just `onSomething` would convert it to `on: { something: ... }` instead of `props: { onSomething: ... }`.
Overall, when I was trying to use JSX with Vue, it very much felt like a second-class feature, tacked on primarily (if not exclusively) to help convert people from React. However, Vue's flavor of JSX doesn't seem to appreciate that the simplicity of how React maps JSX to `React.createElement` is a large part of its brilliance.
In other words, I think that Vue's flavor of JSX introduces just enough magic to make it confusing. It sacrifices consistency for haphazard ergonomics, making the experience frustrating for someone used to JSX being just an XML-like alternative syntax for `createElement` (or `h` or `m`). I think Vue's JSX would be much better if it didn't try to do any magic, and just forced people to write stuff like `<button on={{ click: () => {} }} />` instead.
In the end, I gave up on using JSX with Vue, tried templates for a bit, didn't like them, and moved away from Vue altogether.
Caveat lector: Things might be a lot better now. I tried to read up a bit to see, but I didn't dig very deeply.
---
[1]: https://github.com/vuejs/babel-plugin-transform-vue-jsx#diff...
[2]: But note that not all `domProps` actually need the prefix, either: https://github.com/vuejs/babel-plugin-transform-vue-jsx/pull...
[3]: This actually used to be impossible when I was trying Vue and JSX. It was only added somewhat recently: https://github.com/vuejs/babel-plugin-transform-vue-jsx/pull...