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 [email protected]
npm notice
npm notice 📦  [email protected]
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

Not really up to date on this. I'm much more of just throw something together in Jest/Mocha type. But I think this should not be overlooked. I'd love to see a Solid port of Testing Library. I think this is currently a gap in the narrative for Solid. I'm interested in understanding what it would take to make it happen.

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