I agree with you about the `nameof` comparison, mainly because it deceptively looks like something you'd be able to write yourself (since it's just an attribute), but under the hood it's compiler magic. I'd rather it be more like a keyword or obvious language built-in so there's a clearer boundary between "this is a language feature" and "this is a standard library feature".
I could see both, but things like integer vs float couldn't be determined from the type, since you just have the single `number` type. That being said, you could just convert to an int on the value you're passing in rather than having the interpolation do it for you. Same thing with object vs string, you could pass in `obj.toString()` instead of just `obj` with an `%s`
A suggestion: don't hide the entire store component when you change one of the filters. You can see it flash with unstyled text "loading" before popping back into view. It's much less jarring if you keep the existing content rendered while waiting on the response and swapping it out after the request completes rather than going to a blank screen when you start the request.
My personal preference is more subtle loading indicators near the element that triggered the interaction (the filter inputs themselves in this case) but that's probably subjective. I think at the very least you should keep filter bar visible while it's loading so that the element you're interacting with doesn't disappear while you're using it and pop back into view.
I wish there was a little bit more data on this last chart. How are they measuring 'math progress' here? It looks like the data comes from "online usage data from Zearn math", but how is progress being measured? Does a +53% increase mean that average classroom scores (tests and quizzes?) increased by 53% over where they were before covid? Does it mean the class as a whole covered 53% more of the topics than they would have otherwise? It's unclear to me.
Whatever the measurement, I find it just as interesting that there was such a large increase over pre-covid for the high income zipcodes. My assumption would have been a decrease in the low-income zipcodes (due to access to technology resources for e-learning, more friction in adjusting to staying at home, economic woes effecting low income families more, etc), but the high-income zipcodes to stay roughly the same. It looks like (for math at least) that e-learning is working out great when you have access to the technology, much better than regular in-person school (assuming what they're measuring as 'progress' is actually meaningful to begin with).
>My assumption would have been a decrease in the low-income zipcodes (due to access to technology resources for e-learning, more friction in adjusting to staying at home, economic woes effecting low income families more, etc), but the high-income zipcodes to stay roughly the same. It looks like (for math at least) that e-learning is working out great when you have access to the technology, much better than regular in-person school (assuming what they're measuring as 'progress' is actually meaningful to begin with).
My anecdote working with a lot of engineers who are all currently remote is that they're spending much more time with their kids overall. All throughout the day and not just after work hours. It makes a lot of sense that high income households have math literate parents and those parents now have more time to help their kids become math literate.
Since we're focusing on that last chart, the week the national emergency was declared was also the same week where schools started shutting down en masse; NYC DOE shut down week of March 15[1], and during the enuring weeks and months had issues scrambling to issue tablets to low-income families.
The participation rates for Zearn is, at best, a proxy. And when they say "student progress", I believe it means "students solving puzzles and progressing through the lessons" (whether that's with parental supervision or self-supervised).
I am in this same boat. I recently signed up for Firefox Private Network and I'm in the process of switching over to Mozilla VPN. I think both of these services are great (even if they're essentially white-labels of other companies products) and they're the kinds of things I associate with Mozilla and Firefox. I would also pay for their password manager if it were a little more robust (and if they charged for it) just to get the tight browser integration.
A big benefit of the `users->where(...)` approach is being able to reuse and compose. An example would be conditionally adding a WHERE clause based on some parameters. Using the raw query approach you end up having to do some string concatenation versus managing the state of the some query builder object.
I think that the "query builders" though are just one piece of the ORM that you mention, alongside the change-tracking, data mapping, etc. Having a decent query builder that isn't abstracting away too much of the underlying sql (essentially just mapping 1-to-1) plus data mapping are the sweet spot for me personally.
> According to SCS, the UI would be responsible for fetching that data from the other systems, and would pass all of it as part of the payload to the order fulfillment service.
One potential issue is that the order fulfillment service still needs to validate that the data its getting from the client is correct. For example, even if you send a list of full product details rather than a list of productIds to create the order, the fulfillment service still need a way to associate the Order entity with the Product entities. You could also send the ID with each of the products, but how would you know if the product has since been deleted or otherwise doesn't exist.
You end up needing the order service to either have its own set of knowledge about what products exist in the system for that user, or you need to make the synchronous call to ensure they're real products.
Good point. The solution is obviously going to be context-specific. I suspect in our hypothetical order scenario that the order fulfillment system could get away with not validating the product being ordered.
Of course it would still need a way of capturing the identity of that product. I would guess that the best way to handle that would be to pass a URN or URI for the product. That would still decouple it somewhat from the product catalog system.
In general for these kinds of integrations, you're probably better off avoiding passing around system specific IDs. Pass data instead of IDs (pass the geocordinates or standardized address for a customers delivery address rather than the customer ID). If you have to pass around IDs, then URIs allow for greater decoupling.
Unfortunately the PPP money has all been dried up as of today, and many small businesses weren't able to take advantage of it. This site was put together to track how many businesses have received it, though it relies on self-reporting from the businesses so it won't be entirely accurate: https://www.covidloantracker.com/
There are a few casts that are allowed that I would consider unsafe, particularly around unions of literals or using empty object literals:
// No error here
type Animal = 'dog' | 'cat';
const notAnimal = 'couch' as Animal;
// No error here either
type Food = { isSpicy: boolean };
const empty = {} as Food;
