The documentation contains a few references to issues from the now archived yewstack/docs repository.
Since the docs repository is read-only, the same issues should be re-created here and the links in the docs should be updated to point to the new issue.

"Contribute to our docs" links

• Page: [Components Lifecycle Diagram](https://yew.rs/docs/conce

For the most part this just works, but functions within tagged markup get weird indent assertions, e.g.,

        ${collection.map((item) => {
          const { prop1, prop2 } = workWith(item);  // eslint: expected indentation of 4 but found 10 (indent)
          return html`  // eslint: expected indentation of 4 but found 10 (indent)
            <${Widget} prop1=${prop1} prop2=${prop2} />

I'm sorry to post an issue that is missing crucial evidence, but some debugging of a recent config loading bug makes me suspect that the react-rails railtie.rb may be modifying the load order of initializers, and preventing the values in Rails.application.config being as expected.

Whether this happens or not appears to be partly dependent on where in the Gemfile the react-rails gem is l

To reproduce:

$ npm pack styled-jsx@3.2.4
npm notice
npm notice 📦  styled-jsx@3.2.4
npm notice === Tarball Contents ===
npm notice 6.1kB  dist/.DS_Store
npm notice 599B   dist/_constants.js
npm notice 22.3kB dist/_utils.js
npm notice 8.2kB  dist/babel-external.js
npm notice 46B    babel-test.js
npm notice 753B   dist/babel-test.js
npm notice 41B    babel.js
npm notice 10.4k

I really would appreciate feedback here. It is so hard for me to see it since I've been so close to this for so long and I've developed apps in this manner for 10 years. I'm going to be the worst person to write the documentation since it is all so second nature for me. Yet, I am most likely going to be the person writing the documentation since I understand how everything works so well.

So can

I think having Crank emit errors/warnings in more situations would go a long ways towards compensating for the docs' lack of nuance.

E.g., an async generator returning undefined doesn't strike me as a common thing to want to do, and if someone wants it maybe they should return null so it's explicit. Then Crank could throw an error if an async generator returns undefined. That should

Blocked By: wix/vscode-glean#97

Example:

class Foo extends Component {

  render() {
    return (<div>
      {this.props.foo.map((bar) => <div>{bar.x}</div>)}
    </div>)
  }
}

Current:

 const Foo = props => {
   const foo = useRef();
   const x = useRef();
   return <div>
       {foo.current.map(bar => <div>{x.current}</div>)}
 

It may be nice to ultimately just update these tests to read the data/blocks dir and run tests against each automatically so it's easier to manage these tests