9 Matching Annotations
- Sep 2021
-
-
Update API usage of the view helpers by changing javascript_packs_with_chunks_tag and stylesheet_packs_with_chunks_tag to javascript_pack_tag and stylesheet_pack_tag. Ensure that your layouts and views will only have at most one call to javascript_pack_tag or stylesheet_pack_tag. You can now pass multiple bundles to these view helper methods.
Good move. Rather than having 2 different methods, and requiring people to "go out of their way" to "opt in" to using chunks by using the longer-named
javascript_packs_with_chunks_tag
, they changed it to just use chunks by default, out of the box.Now they don't need 2 similar but separate methods that do nearly the same, which makes things simpler and easier to understand (no longer have to stop and ask oneself, which one should I use? what's the difference?).
You can't get it "wrong" now because there's only one option.
And by switching that method to use the shorter name, it makes it clearer that that is the usual/common/recommended way to go.
-
- Aug 2021
-
github.com github.com
-
There is always a way to work around that by doing expr as unknown as T, but it stops people making basic errors.
-
- May 2021
-
stackoverflow.com stackoverflow.com
-
Because constants in Ruby aren't meant to be changed, Ruby discourages you from assigning to them in parts of code which might get executed more than once, such as inside methods.
-
- Feb 2021
-
github.com github.com
-
Enforces better architecture
-
-
-
Trust me, I thought a lot about #validate and its semantics, and I am gonna make it even more "SRP" by making Form#errors and #valid? semi-public. All that happens via #validate reducing the possible wrong usage for users.
-
- Dec 2020
-
github.com github.com
-
The only solution that I can see is to ensure that each user gets their own set of stores for each server-rendered page. We can achieve this with the context API, and expose the stores like so: <script> import { stores } from '@sapper/app'; const { page, preloading, session } = stores(); </script> Calling stores() outside component initialisation would be an error.
Good solution.
-
-
-
This would be cumbersome, and would encourage developers to populate stores from inside components, which makes accidental data leakage significantly more likely.
-
which makes it much harder to accidentally keep logged-in state visible after a client-side logout
-
- Nov 2020
-
gist.github.com gist.github.com
-
There was a major refactoring in the resolver (https://github.com/webpack/enhanced-resolve). This means the resolving option were changed too. Mostly simplification and changes that make it more unlikely to configure it incorrectly.
Linked from: https://stackoverflow.com/a/36574982/47185
-