@ekhi#vue has some really nice component frameworks
I already used #vuetify, #quasar and #naiveui at work and they have all their benefits and trade-offs
When you develop a library for the JS ecosystem - be it #React, #Svelte, #Vue whatever, do the #JavaScript community a favor and implement it in #TypeScript.
And no, I don't want to have a loosly dangling d.ts file somewhere. Go TypeScript natively!
I can't use your beautiful Vue js component in my Vue TS app, because it doesn't provide typings for it's slots! 😠
By the way, if you want to support me, this project is exactly the right thing to sponsor me: https://github.com/sponsors/Shinigami92
I'm working on the project in my free time and I've already invested about 10 net hours and plan to get far so that one day it can finally be used in #vue and other frameworks
:javascript:
Vanilla Reactive Store Implementation:
This is a popular implementation of reactive store based on JS Proxy objects.
However proxies are created even on individual array elements being accessed.
I understand that is required, but would this not generate a huge amount of proxy objects?
It seems like Vue internally implements a more comprehensive pattern based on this approach.
#shadowDOM partners with the likes of :not(:defined) to make progressive enhancement a more natural part of component development than ever.
#declarativeShadowDOM builds on top of that, and once Firefox ships things powerful API the distance between "page load" and "page needs JS" can be even further apart.
It's powerful to lean into the existing web APIs to learn new and exciting ways to support our clients while continuing to push the boundaries of those APIs at the spec level.
Placing your #shadowDOM in #customElements also makes them hyper-portable. So, whether the distance between "page load" and "page needs JS" is short, like in an #AdobePhotoshop, or long, like a #staticDocumentationSite, you have the ability to benefit the consumers of your content in a way that is most valuable to the goals that they have.
Doing this also makes leveraging that content across a myriad of app contexts (whether is #React, #Vue, #webComponents, #angular, or fully custom!)
I've built a #transpiler in #Rust, compiled it to #WASM and integrated it into a #Vue app! :awesome:
It's called selecuery.✨
It can transpile X++ select statements into query expressions. If you think "X++" is a typo and you don't have any idea of what I'm talking about, don't worry.😄
Have a look at the video below.
This project is dear to my heart! ❤️ I've started it 2019 for learning #RustLang.
I think, I've been transpiled during this project as well.🤪
I built a magnifier with @TauriApps, @vite, #vue and #typescript called "Milky Warp" 🌌! I'm doing a few presentations for http://roller-coaster.app, and I noticed it's not easy to read text on a screen or a small video. I couldn't find a good magnifier tool, so I built one!
Of course, I didn't want to go through the hassle of setting up a C++ project with some weird shaders, so I decided to go with the awesome #Tauri. Milky Warp is open source, you can give it a look, or follow this thread for a few technical explanations.
It requires a bit of config, but not too bad, given that it's bleeding edge.
What tripped me up in the very end:
You need to call init() first from your wasm module, otherwise error "wasm is undefined", when calling your function.
I love how #javascript generally goes with the fractal structure of files, but I'm trying to see how #vue does it since it seems like it might not be as opinionated about this.
There's lots of different things to work on in Dropserver, but right now I am going through the frontend code to bring the code quality up (it's a bit of a mess), move to using Pinia and the "setup style" of #Vue SFCs (huge reduction in boilerplate).
Also, I'm improving the #UX where I can. Like today, where I'm trying to make clear this error condition where your data is the wrong schema for the app. First pic: things are fine. 2nd: Data Schema mismatch.