9 Matching Annotations
- Feb 2021
-
www.honeybadger.io www.honeybadger.io
-
Now if you think about it, PJAX sounds a lot like Turbolinks. They both use JS to fetch server-rendered HTML and put it into the DOM. They both do caching and manage the forward and back buttons. It's almost as if the Rails team took a technique developed elsewhere and just rebranded it.
-
- Oct 2020
-
github.com github.com
-
I'm suggesting there should be a way to write lifecycle related code that also responds to changing props, like how useEffect works. I think how React handles this could be a good source of inspiration.
-
-
final-form.org final-form.org
-
both copied much of their API from Redux Form, so, despite working very differently under the hood, there is a lot of overlap in their APIs.
-
- Sep 2020
-
devblogs.microsoft.com devblogs.microsoft.com
-
If you’ve used Flow before, the syntax is fairly similar. One difference is that we’ve added a few restrictions to avoid code that might appear ambiguous.
-
-
github.com github.com
-
For context, the previous API had a lazy promise. Currently I’m thinking we could just return a closure like in the React API
-
-
stackoverflow.com stackoverflow.com
-
This is the same as useEffect in React, incidentally — the function must be synchronous in order to avoid race conditions.
-
-
github.com github.com
-
The main rationale for this PR is that, in my hones opinion, Svelte needs a way to support style overrides in an intuitive and close to plain HTML/CSS way. What I regard as intuitive is: Looking at how customizing of styles is being done when applying a typical CSS component framework, and making that possible with Svelte.
-
-
github.com github.com
-
Does it look like a decorator plugin in Ractive, right
-
-
github.com github.com
-
The more I think about this, the more I think that maybe React already has the right solution to this particular issue, and we're tying ourselves in knots trying to avoid unnecessary re-rendering. Basically, this JSX... <Foo {...a} b={1} {...c} d={2}/> ...translates to this JS: React.createElement(Foo, _extends({}, a, { b: 1 }, c, { d: 2 })); If we did the same thing (i.e. bail out of the optimisation allowed by knowing the attribute names ahead of time), our lives would get a lot simpler, and the performance characteristics would be pretty similar in all but somewhat contrived scenarios, I think. (It'll still be faster than React, anyway!)
-