229 karma · joined July 3, 2014
LinkedIn: linkedin.com/in/sfilipov
- the argument passed to useState is initial state, not "forever state". It will seed prevItems for the first render. But later when items prop changes, it's on you to detect the change to what you have as prevItems so far and call setPrevItems yourself.
- items is coming as a prop from outside, prevItems is whatever you set it to last time using setPrevItems
- calling a state setter (setPrevItems / setSelection etc) will always cause a rerender. That's why if you don't have the if condition you have just created an infinite loop - you are inside a render, and if you unconditionally call setX that causes another rerender later etc etc
- that's why I am not a big fan of this particular "Better" example and prefer the later "Best". Avoiding calling state setter function from inside render will make your life easier.
I agree with your overall comment. Note that Hasura doesn't use the native row level security in Postgres. They implement the layer themselves. There are two reasons: 1) Hasura is older than the first release of Postgres that included the row level security feature. 2) Their implementation scales better when there are a lot of users subscribed to the same GQL Subscription. When using row level security, every user's query result looks different, so they need to create a database subscription / polling for each user GQL Subscription. Their implementation allows them to have a single PG subscription (well they mostly do polling), get all the data back, then strip down on the way out to the GQL subscribers.
For example, nobody is forcing me to use Docker from the start. I don't have to use it until I decide the development or deployment pain is big enough that I will learn how to use Docker. Similarly, why do server side rendering when you can have a perfectly working project without it. Add server side rendering later, when you project actually has real features. Not from day one. The temptation to use cool tech from the start is difficult to ignore at first, but after a few attempts to do a side project, only to give up before you've even started, it gets easier to appreciate stack simplicity :)
Trying to keep code as simple as possible from the start is more difficult, i.e. you might be structuring your code too naively and regret it later when you try to refactor. But as we know, abstracting too early creates similar if not worse problems.
You are right that TypeScript aliases don't work like Haskell ones (which are considered different, and type checked). In TypeScript you can use "branded types" to work around the more loose structural typing:
type Firstname = string & { readonly brand?: unique symbol }
I agree that if you are building ORM with the intention of hiding so many SQL details that the developers don't need to learn SQL, you'll run into problems.
SQLAlchemy on the other hand starts simple, but is flexible enough that you can do inner/outer joins, you have different loading strategies etc. It is quite nice if you are proficient enough in SQL.
When writing complicated select queries, I'd start by writing the raw SQL then spend my time representing it in SQLAlchemy. It's a bit less than double the work sometimes, but working with the SQLAlchemy objects in Python is quite nice as long as you pull them in an efficient manner. SQLAlchemy just feels like a well thought out ORM.
AJAX using jQuery is so convenient. I would rather not write these in vanilla JS.
I understand that if I'm running a managing runner in machine mode with limit=10 then it can start a maximum of 10 machines. What does "concurrent" affect in this context. I don't want the managing runner to do any builds locally -- just to send to runners managed by machine.
[1] https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma...
Edit:
Ignore me. I found the answer on the same page [2]:
[2] https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma...
I was also running into Haskell compilation problems that were fixed by running Ubuntu in a Vagrant environment but speed was slow. There isn't good NFS support on Windows either (there is some).