It’s a nasty one because there’s no “reject all” button, it requires manually unchecking all checkboxes instead.

That one uses a nasty cookie notice.

You may have initially misunderstood my idea, but you did help.

And I implemented it in the meantime, as a library named hybrid-array (after your suggestion).

Not all transformative array methods have been checked yet, no unit testing nor comments have been written yet, no benchmarks have been performed yet, but these will happen.

Thanks.

Please read the conversation : as long as it’s described as microblogging then it’s not a good fit.

Tell me about it.

I’m not even sure what blogging is, much less microblogging

It’s simple, actually : blogging is posting large content, microblogging is posting short content (hence micro).

That’s why Mastodon is microblogging, for example : because their character limit is 500.

https://writefreely.org/ might be the fediverse blogging platform you’re looking for

It would be, except it doesn’t allow any interaction between authors and readers, making federation almost pointless, it also lacks attachments hosting and other blog stuff.

There’s also Plume, which has slightly more features, but still lacks a lot, isn’t actively developed and is currently suffering from massive spam.

So, to conclude, there currently isn’t any interesting federated blogging platform.

What do you mean by better microblogging support ?

By the way, microblogging ≠ blogging. Speaking of which, Lemmy’s post character limit is 50K. What’s Kbin’s ?

Hi, I’m also interested in using Lemmy as a blog. Did you explore this further ? Thanks

True, but less convenient than using an array in the first place.

I used to enjoy the flexibility that JS provides. And IDEs do a pretty good job of filling the holes!

Exactly.

My last project, I went all in on typescript. And I have caught so many more errors before even compiling. It’s like having tests. It gives a hell of a lot more confidence.

I can understand that too. Although, IDEs also catch a lot of type-related errors in vanilla JS.

I’m not a TypeScript person, sorry. 😅

Hi,

I’m feeling the same and wondering the same, did you ended up trying this, and if yes, do you have some advice on how to manage this particular use case ?

Thanks

dictionary/array hybrid

That’s a name, thanks !

Serialization might not behave as you would expect (JSON.stringify)

Actually, my implementation idea relying on Proxy don’t have this issue.

As for other implementations, they do have this issue, but as they say, hybrid array use cases don’t generally involve the need to stringify, and even when they do, using Object.defineProperty with { enumerable: false } (or replacing the toJSON method) would fix it.

3rd-party functions might not be able to deal with your data structure properly (again, potentially unexpected behavior). You can’t easily access array methods (find, filter, map etc).

Actually, it would still be an Array, so no, there shouldn’t be any problems, and yes, those methods definitely work, which is precisely what said I want to achieve.

How do you distinguish between ID access and index access?

If your IDs are integers then there is no need for an hybrid at all, precisely because all you have to do is put each item at the same position as their ID.

It’s harder to reason about access time of lookups. However, this might not be a concern of yours.

I’ll definitely run benchmarks so that users would be aware of performance losses, if any. But use cases of hybrid arrays are mostly small datasets so it usually shouldn’t be a concern indeed.

It may cause confusion if you’re working with other developers.

If I implement this, it will be as a documented and commented package, so it shouldn’t be that much of a problem.

I just found two packages that do the same thing as I did :

• indexed-array
• keyed-array

The last one comes with a blog post explaining the same things I did !

Yes but no thanks, cf. my reply to @Zushii@feddit.de.

My goal is to be able to both easily get an item by ID (using data[id]) and easily get an item by properties (using data.find()).

Meanwhile, just like Object requires Object.values(object) before calling find, Map requires [...map.values()], and it also have the additional inconvenient of requiring a call to map.get to get an item by ID, so no, it’s even worse for my goal, but thanks.