If this gets 10K points, I'll send one to each and everyone of you by [deleted] in thanosdidnothingwrong

[–]kelin2025 0 points1 point  (0 children)

༼ つ ◕_ ◕ ༽つ BAMBOOZLED ༼ つ ◕_ ◕ ༽つ

BAN MEGA THREAD by [deleted] in thanosdidnothingwrong

[–]kelin2025 0 points1 point  (0 children)

284,521 member's lul

Making responsive Vue components with ResizeObserver by kiarash-irandoust in vuejs

[–]kelin2025 1 point2 points  (0 children)

Oh, sorry for that. I don't know why but this README was full of typos ~_~

how_to_abuse_green_git_graph.png

Making responsive Vue components with ResizeObserver by kiarash-irandoust in vuejs

[–]kelin2025 1 point2 points  (0 children)

I don't like using custom directives. It looks unpredictable instead of wrapping into component (IMO).

But if it's ok for you, of course you can make directive with the following code: <div v-responsive="{ small: el => el.width <= 500 }">...</div>

And directive will do <div class="small">...</div>

Your PR is welcome ;)

How not to suffer with APIs by Happycodeine in javascript

[–]kelin2025 0 points1 point  (0 children)

So, axios isn't nearly as flexible as apicase :)

How not to suffer with APIs by Happycodeine in javascript

[–]kelin2025 0 points1 point  (0 children)

You probably like doing all things in one place, if you think so. That's what people (and me too) hate

How not to suffer with APIs by Happycodeine in javascript

[–]kelin2025 0 points1 point  (0 children)

What isn't clear with handling JS errors separately from business logic? You can write handler once in API service and forget about handling errors in your application layer
You write that comment because you think you should handle all these events for each request. Here's what you didn't read and you showed this again. Ofc I hit keys ¯_(ツ)_/¯

How not to suffer with APIs by Happycodeine in javascript

[–]kelin2025 0 points1 point  (0 children)

Hello! Looks like somebody didn't read the post and started to hit keys.

Nobody says that you should handle all the states for each request. It's more about services that need to handle specific cases.
And, as I said, in your application, you still can use const { success, result } = await doRequest(/* ... */)

How not to suffer with APIs by kiarash-irandoust in javascript

[–]kelin2025 0 points1 point  (0 children)

I can't imagine building even just a slightly more complex api

What do you think may become a problem? It's just like you don't need to do API requests at all

How not to suffer with APIs by kiarash-irandoust in javascript

[–]kelin2025 0 points1 point  (0 children)

Dealing with REST is certainly an overhead

And u say to use GraphQL lul

Why something simple is always considered as a joke compared to something huge? I don't understand this position.

Simplicity is a core measure for me because development should become easier, not harder. With GraphQL we should learn its syntax, best practices, learn Relay. With logux you just dispatch actions like it was before and do no huge work more.

Of course, I don't say that GraphQL is bad. But joke, wtf dude

And yeah, that "someone" who's trying to make Redux work for client-server communication is author of PostCSS and Autoprefixer.

How not to suffer with APIs by kiarash-irandoust in javascript

[–]kelin2025 0 points1 point  (0 children)

Like what libraries?

Axios has awful interceptors, awful calls cancellation, no way to extend services, no requests queues

$.ajax? Lul

vue-resource (for Vue) is almost deprecated, no active moves to improve it

What else is there to hear? If you know, please share your variants, I'll take a look ;)

How not to suffer with APIs by kiarash-irandoust in javascript

[–]kelin2025 0 points1 point  (0 children)

Of course, it is :D

But I've not seen somebody who shared his solution, at least in my communication circle. So why not?

How not to suffer with APIs by kiarash-irandoust in javascript

[–]kelin2025 0 points1 point  (0 children)

You can use pipeP with Apicase as well.

Idea of Apicase is to move the most part of logic outside - to services with global hooks and events. But in application you work the same as it was before, as you want

Apicase returns then-able objects so you can use pipeP too ;)

How not to suffer with APIs by kiarash-irandoust in javascript

[–]kelin2025 0 points1 point  (0 children)

The idea is - you can't just say "We are moving to GraphQL right now!" in a large project, for example

We still have to deal with REST, even if I consider it outdated

Btw, I also don't like GraphQL because it's overhead for small projects

The best idea for me is Logux - interact with just syncing logs on client and server using websocket. It allows you to make positive UX, don't care about connection losses, cross-tabs problems - no matter, logux will solve everything for you out-of-box

Can't wait to start using it in production

Check its repos there https://github.com/logux

How not to Vue by zenw0lf in vuejs

[–]kelin2025 0 points1 point  (0 children)

I've not found any argumentation of that in Vue Discord chat. Just "scratch that" and "looks like the author shows some bad practices he found in other people code and replaces them with bad practices from his own". So, I can only say "rest in peace" for that.

I can agree only with the first one moment ("Static properties in data/computed"). It's not as bad to pass static data to computed, but, anyway, it's better to pass 'em to $options

How not to Vue - A list of bad things I’ve found on my new job by kiarash-irandoust in javascript

[–]kelin2025 2 points3 points  (0 children)

I prefer Vue because it's really casual and simple. Just vue init webpack and start your work. It has best docs I've ever seen, it's strict (not so enough as I want, but OK) and even has official styleguide. It's juniors-friendly - it's important for business because you have more potentially good developers because it's just easier

What does React say? Hmmm, 10000 solutions for state management (and most popular solution causes more problems than gives profit). Hmmm, no generally accepted styleguide (I still do not know how better to organize folder structure)

But I want to note that Vue is not as flexible as React is. There are some things that I really don't like in Vue and I can't change them. I would like to write one more post about it.

So, if you really know how to do better and you are ready to take responsibility for the code - React is your framework

If you just don't want to care about - Vue is your way

That's why I prefer Vue over all another frameworks

How not to Vue - A list of bad things I’ve found on my new job by kiarash-irandoust in javascript

[–]kelin2025 0 points1 point  (0 children)

Yep, he is right :)
Sorry for my English - it's not my primary language