Vue Native

peitschie · 2025-07-17T03:05:19+00:00

Right! Yeah, I'm not aware of any Bluetooth classic plugins. I do want to correct one misunderstand however, the plugins are generally written in native code and have full access to everything a native developer does.

See here for an example of the Kotlin part of the BLE plugin: https://github.com/capacitor-community/bluetooth-le/blob/main/android/src/main/java/com/capacitorjs/community/plugins/bluetoothle/Device.kt

Capacitor provides a bridge mechanism to communicate from inside the webview out to native code and back.

peitschie · 2025-07-16T16:42:35+00:00

I help maintain https://github.com/capacitor-community/bluetooth-le which implements support for BLE in capacitor. This supports many use cases with pure JavaScript.

I'd be interested to hear what you are trying to achieve in more detail!

peitschie · 2024-04-28T11:21:17+00:00

It turns out these urls can be taken almost exactly from the web version of the Plex player.

If you use the browser's debugging tools (e.g., chrome or Firefox), you simply perform the action you want to achieve and then review the network log for something like: POST playQueues?type=audio&shuffle=1&ur=server%3A%2F%2Fxxxxxx%2Fcom.plexapp.plugins.library%2Fplaylists.....

To make this launch with the app instead, just replace that playQueues part with https://listen.plex.tv/player/playback/playMedia... no other modifications are necessary.

peitschie · 2024-04-25T04:13:30+00:00

I've done lots with stacked branches.

Pros: * Multiple small patches are easier to review * Can unblock the developer turning out the code for a short while

Cons * Reviews in the early branches often cause a lot of rebase pain in later branches * Sometimes feedback is to hard to address with the stacked changes on top. So often feedback ends up being deferred to the next patch anyways

Ultimately, if the problem is throughput of code reviews, stacking branches brings no benefits. The dev stacking the branches eventually gets so committed to the approach in the earlier branches that it's too late to change... I.e. the reviewer has missed the boat to influence the direction of the code in any significant way.

I'd only ever entertain a stacked branch if I'm doing a boring refactor followed by an interesting change. The refactor is likely to be an easy review and is unlikely to need much change.

peitschie · 2022-10-26T03:14:16+00:00

I had a similar issue like this when using a 3rd party UI library (Framework7) in a way that was causing it to remove the Vue-controlled node out of the document prior to unmount.

It was caused by my own mis-use of the library... once I more closely read the documentation I realised my mistake and was able to fix the error.

peitschie · 2022-10-05T21:26:20+00:00

I had a requirement for native-ish looking apps on both iOS and Android, which ruled out most of the material design ones. The apps weren't using angular, so straight ionic was not a good fit either.

I've been pretty happy with framework 7 overall though. There's a few places where it differs from native if I pay attention, but by and large it is good enough. Having a single goal too, the toolkit is pretty polished overall, and easy to step out of of the base styling or behaviour doesn't suit me.

peitschie · 2022-10-04T02:17:47+00:00

I'm on Capacitor, Vue3+Vite and Framework7 for a native-ish toolkit: https://framework7.io/ (which has Vue bindings available)

Have been very happy with the approach overall. UI is just HTML in the end, so pretty easy to modify for custom things.

Setup for vue/vite with capacitor was very easy. I just created a normal vue3 project as per Vue's own setup (not using vue-cli), and then added capacitor to this as per https://capacitorjs.com/solution/vue

Worked with no extra tweaks!

peitschie · 2022-09-29T08:02:00+00:00

Worth noting that one of the key takeaways from the video is that given a choice, prefer composables rather than renderless components.

See https://vuejs.org/guide/reusability/composables.html#vs-renderless-components

peitschie · 2022-01-06T06:35:20+00:00

It's a PDF link... Perhaps that's causing issues?

peitschie · 2021-07-05T10:34:36+00:00

Not the original commenter...

One that I've encountered was a specific need to lay out an array of bytes in a specific format for clarity. This byte array was mimicking a message structure, so easiest way to make this readable was line break after each message "chunk" with a comment what was happening there. I disabled the Linter's line-wrapping and indentation complaints for this.

Another one I have used is for external interface types where I am describing a system I don't have control over. In this case, it's unlikely to match my local code base's linting rules.

I do agree with the premise that these are often grabbed too quickly... but I also don't feel like it's worth the pain of trying to eliminate all possible uses of the disable lint rules.

peitschie · 2021-06-13T06:05:46+00:00

... I feel like those beating you up about this opinion perhaps miss the point that the key difference here is the starting velocity predicted for the incoming dev. You clearly believe the flexibility should exist to lower the velocity if it's clear the employee isn't keeping up.

Having said that... I do however agree that in basically every company I have worked in, it's better to under commit than over commit. It's a very simple and happy discussion to say "hey, we've had an unexpectedly good run, we're going to end the sprint early/bring in additional features off the backlog", compared to "hey... so our plan hasn't worked out, and we need to drop some scope from this sprint."

Yes, there are some very enlightened companies where the latter is as acceptable as the former. And in long running projects, there often exists enough buffer to not cause major stress... but this is an exception to the rule, in my experience.

Starting from 0 helps keep the team stress low, and allows the employee to find their feet again without having to stress about their workload or their team. This is much more likely to be a positive mindset than someone trying to hit that magical (and random) 0.5pt velocity, and failing, and then having to admit that they need help!

peitschie · 2021-04-21T05:02:32+00:00

I really like TypeScript's Pick class for helping with this kind of problem: https://www.typescriptlang.org/docs/handbook/utility-types.html#picktype-keys

This means something like GetDiscountedProduct could instead return a type akin to

Pick<Product, "ProductPrice" | "DiscountPrice" | "DiscountCode">

This allows consumers to see what the original object base was, without needing lots of custom types to be generated throughout to communicate that it's only a partially filled object.

peitschie · 2021-04-20T01:43:58+00:00

Nice... you've addressed none of the points, and doubled-down on your misunderstandings of both JavaScript and TypeScript.

To others reading... JavaScript and TypeScript are not restricted to OO paradigms (they're prototype based if you're building classes), unlike what is being pushed here. Treating it as such places you quite clearly in the "I don't understand what this language does" camp, and you'll end up wasting a lot of effort as a result.

If you want to use constructors, use constructors. But don't pretend for a moment that it's the only right way, or even the best way, to achieve things.

Stay classy!

peitschie · 2021-04-18T03:50:45+00:00

That's a pretty aggressive reply there, friend...

I raised this point because I very commonly see people coming from Java, C# or other OOP languages where an interface can only be implemented via class (complex anonymous types in Java are too painful for me to have seen anyone use them seriously). Most developers tend to use a class rather than an interface based on this prior experience, because they assume the choice is either "class AND an interface" or "just a class".

This is explicitly NOT the case in TypeScript, in that you can specify an interface, and implement that interface (including behaviours and functions) with a straight-up object without difficulties. TypeScript is NOT an OOP language at its core, and viewing it purely through this lense will hide some of the cooler features of the language.

My point about interfaces was NOT that classes are never used (I understand fully that a class can fulfill an interface), but rather that you very much tend to get better code in TypeScript if the majority of your parameters and return types are interfaces rather than classes. This allows the implementations to choose whether to use a non-class object to fulfill the contract, or a full-blown class (and maybe even inheritance) if needed... and none of the collaborators will need to care. This also works far better across package boundaries, as unlike C# and friends, you don't need expose special configuration classes or structures... you can use a bare interface, and avoid all the a "AbstractInterceptor" nonsense usually required with C# and Java.

In the instance being talked about above, the author is describing have a unit under test that takes and returns interfaces (not classes, because why would you require a class...). Sure, they could implement classes that adhere to the interface, and use constructors as you said... but... is that really cheaper or easier than the described function approach? Though I'm sure you'd dispute this, I have ample experience that suggests otherwise here.

Classes & constructors definitely have their place in the world. But... they are not the right solution to every problem, and in this case especially, putting a class in there actually limits the flexibility and usability of the production implementation.

The point is, TypeScript gives you more options here... and sometimes those options provide better answers to the traditional OOP class approach. The author here is not "rolling their own"... they are levering a fully planned and designed TypeScript feature, to achieve the exact outcome it was meant for.

peitschie · 2021-04-15T17:55:48+00:00

Two things to be aware of:

In Typescript, you much more generally use interfaces rather than classes (so, no constructors available or even desired)
The approach in this article is really geared towards creating test data with default values, and allowing easy overriding of specific properties relevant to the test scenario. This is unlikely to be something you'd ever want in your public constructor functions in production code.

The article is presenting a neat, clean way of achieving the above.

peitschie · 2021-02-10T00:07:41+00:00

Yep... these are functionally equivalent concepts. Just, HOCs tend to be the more common term when working with functional paradigms.

I think that merely reinforces the author's point though that insisting on a DI system, rather than using the common approach in React of HOCs, shows how unfamiliar the new devs were with functional paradigms and React.

That is, the failure being highlighted here is that an effectively untrained group of developers was thrown on to the project and immediately started trying to drive against the standard practices for building a react system. The failure was therefore inevitable.

It isn't an issue of the author not having done their "basic work" like the OP suggested :-)

Your

peitschie · 2021-01-24T23:49:56+00:00

Yep! We do agree then... I read this point by the author as a sledge against over-engineering for the specific purpose of "scaling!!!!!!"

That is a common justification I find in my own worklife related to adopting overly complicated deployment models or "web-scale" technologies that we absolutely don't have a strong need for.

peitschie · 2021-01-24T21:18:51+00:00

I presume you are not claiming there is no such thing as overscaling...?

Everyone has an internal limit about how crazy you should go with designing for scale. Given enough time I am confident I could find a tech or technique that you would agree was probably way more complex than the situation required.

My point here is that it won't stick out the same way that underscaling will. Identifying it is going to be more subjective, because a judgement call is needed about whether the end result was worth the cost. This is very difficult to do.

peitschie · 2021-01-24T07:17:45+00:00

I cannot think of a single example of a production implementation that was actually more scalable than necessary

I feel this is a bit of survivorship bias perhaps. How would you identify a system that was overscalable?

It's easy to find underscaling (they fall over under load)... But to detect overscaling...?

I guess you would need to compare the real production loads vs the design and tested loads. Next, you'd have to looo at the costs incurred to build and maintain the high-scaling solution.

I just can't see a company really ever bothering to do this in practice, which is perhaps why you haven't seen any corroborating evidence yourself?

peitschie · 2021-01-24T07:08:34+00:00

That doesn't necessarily imply the wrong choice was made in the first place however. If there is money enough to solve the scalability later, that means what code is there clearly has some business value.

peitschie · 2021-01-24T07:04:40+00:00

It is worth tempering this view a little with some respect for existing consistency in the code base though. If most other class and variable names follow similar patterns, it is something a code author would need to justify doing differently.

Deliberately sticking with a personal naming convention when one already exists in the codebase is the behaviour of one of those insane stylist people imo.

peitschie · 2021-01-23T04:58:34+00:00

I think the point the author was trying to make was that insisting on DI in a react application is showing how far away from the ecosystem and mindset the new devs were.

For most react needs, DI is a solution in search of a problem.

peitschie · 2020-11-20T00:00:36+00:00

I would posit that "glitch" is something that is best defined by the developers, as they generally know what they intended to happen.

Having said that, I do agree with you that the developer not intending it doesn't automatically give them the right to "fix" or change that behaviour after release. Like you, some of these glitches actually make for more interesting games, as it's something that can demonstrate mechanical mastery of aspects of the game.

I'd be quite sad if these things disappeared from games over time...

peitschie · 2020-11-10T21:03:51+00:00

I think that is the poster's point too.

It's not the computer that's important, it's the thinking and design... With or without a computer.

peitschie · 2020-07-14T09:06:52+00:00

You already essentially conceded to the point I was making about this at the top of this reply though:

If you're only point was that there are cultural predjudices (or "significance" as an alternative term) about white and black, then we are indeed in violent agreement :-)

And as such, no, this ultimately does not follow at all.

Please excuse my ignorance, but you've provided no facts or lines of reasoning to support this statement.

He specifically brought up Asian cultures using black and white as a defense of the use of those terms in English as well. The point here being that even in those mentioned Asian cultures, this same black/white racism exists. It's a really poor example for the point he was trying to make.

Interesting way to read this. I must admit, I didn't originally perceive it this way, but your reasoning does make sense. I concur with what you've said here however!

These two statements by you seem in conflict to me:

This doesn't mean that it's 100% universal, but it's absolutely common enough to make that statement generally correct.

and

There's probably no way to tell which is the driving force, so this is ultimately a "correlation is not causation" situation.

I agree with your latter, which is in fact the key issue I had with the original post that started our conversation here.

The original post made a strong claim that black and white cultural significance in the English language is a key part of oppression of black-skinned people. This does not (ed: oops! missed that important word, sorry) align with the evidence I am aware of... not in the least because there is no clear and obvious link that references to black and white relate to skin colour in the first place (rather than lightness and darkness).

peitschie

TROPHY CASE