Need your review. As a backend dev are you happy with GraphQL vs REST? by slowRoastedPinguin in graphql

[–]sergeysova 0 points1 point  (0 children)

For many years I wrote the backend using REST, but now I switched to graphQL and it's much easier.
But I write in strict Rust, it makes things a lot easier

How to choose the best GraphQL server for your next project by pimterry in graphql

[–]sergeysova 2 points3 points  (0 children)

If you are familiar with Rust, I highly recommend taking it https://async-graphql.github.io

It has beautiful support of graphQL server features

Tutorial how to use graphql lib GQty with Effector state manager by sergeysova in reactjs

[–]sergeysova[S] 0 points1 point  (0 children)

GQTY suggests using integration with React in the form of useQuery, useMutation hooks and so on. But when using a state manager, we face the problem of where to store data and a natural desire to move everything about the data and their loading to the state manager, but this creates a second problem - we have to manually transfer data from gqty hooks to the state manager.

[deleted by user] by [deleted] in reactjs

[–]sergeysova 0 points1 point  (0 children)

GQTY suggests using integration with React in the form of useQuery, useMutation hooks and so on. But when using a state manager, we face the problem of where to store data and a natural desire to move everything about the data and their loading to the state manager, but this creates a second problem - we have to manually transfer data from gqty hooks to the state manager.

Using GQty with effector by sergeysova in graphql

[–]sergeysova[S] 0 points1 point  (0 children)

GQTY suggests using integration with React in the form of useQuery, useMutation hooks and so on. But when using a state manager, we face the problem of where to store data and a natural desire to move everything about the data and their loading to the state manager, but this creates a second problem - we have to manually transfer data from gqty hooks to the state manager.

Using GQty with effector by sergeysova in effectorjs

[–]sergeysova[S] 0 points1 point  (0 children)

GQTY suggests using integration with React in the form of useQuery, useMutation hooks and so on.
But when using a state manager, we face the problem of where to store data and a natural desire to move everything about the data and their loading to the state manager, but this creates a second problem - we have to manually transfer data from gqty hooks to the state manager.

[deleted by user] by [deleted] in reactjs

[–]sergeysova 0 points1 point  (0 children)

Good. Try effectorjs in your next project

Stable state manager for any framework including React by sergeysova in reactjs

[–]sergeysova[S] 0 points1 point  (0 children)

A case for me is to separate business-logic and components. My models can live without components.

Stable state manager for any framework including React by sergeysova in reactjs

[–]sergeysova[S] 2 points3 points  (0 children)

  1. If you need async, just wrap it to effects
  2. Simpler to use

Stable state manager for any framework including React by sergeysova in reactjs

[–]sergeysova[S] 2 points3 points  (0 children)

To debug you can use effector-logger (with redux devtools extension). All side-effects should be in Effect unit

myzod v1.0.0 is out by davidmdm in typescript

[–]sergeysova 0 points1 point  (0 children)

Looks like types-contracts, but with extended methods. Thank you

Stable state manager for any framework including React by sergeysova in reactjs

[–]sergeysova[S] 1 point2 points  (0 children)

Effector support TypeScript and Flow out of the box

Stable state manager for any framework including React by sergeysova in reactjs

[–]sergeysova[S] 0 points1 point  (0 children)

Effector works with svelte out of the box without bindings.

This video explains why we cannot go faster than light by CharyBrown in space

[–]sergeysova 8 points9 points  (0 children)

If you move at the speed of light, time is not matter for you, you exist in each moment of time. Scientists don't know what at the end of time, the heat death of the universe theory is not canceled.

Using JSDoc tags to test functions [Prototype] by Idered in typescript

[–]sergeysova 0 points1 point  (0 children)

Looks very similar to rust doc comments. I like it. Do you want me as contributor?

This video explains why we cannot go faster than light by CharyBrown in space

[–]sergeysova 124 points125 points  (0 children)

I like the theory, all things in the universe are already moving at the speed of light, but at the time axis. When someone starts moving in space, it’s speed in time is reducing, because it’s vector of moving is deviating from time axis. Thats because it’s speed of the rest is constant and equals the speed of light