pinchcramp

I clearly didn’t read it.

I love the honesty. It’s really refreshing to see someone take accountability instead of becoming defensive.

Looking back on my career, submitting your first merge/pull request can take anywhere from a few hours to several weeks (we’re talking about 8+ hour work days). And that’s at companies that have an onboarding process and coworkers you can ask for help and explanations about the code base, architecture etc.

Getting into someone else’s code (this may include your past self) is almost never easy and often feels convoluted, because it’s very difficult to see the context that existed at the time when the code was written. And by context I mean everything that influenced the decision to write lines the way they were written, including undocumented discussions, necessary but non-obvious workarounds, understanding of the problem and solution space by the dev, general state of mind of the person writing the code and more.

Don’t beat yourself up because you couldn’t contribute in just a few hours.

I would first reach out to the devs on IRC/Discord/Matrix and express interest to contribute and see how they react. You don’t know if they would even accept your PR, so I wouldn’t do too much work upfront.

Then, when they are open to work with you, find out if they are willing to help you ease into the code. What files should you study to implement the changes that you’ve discussed earlier, any considerations that are not obvious, is there legacy code that you shouldn’t touch etc.

It’s important to keep in mind that (collaborative) software development is more than just being able to write code. And a lot of the surrounding work is not very glamorous or fun.

I hope that helps and wish you good luck! 🤞

I would have written that comment if you hadn’t already done it.

I don’t know exactly why people think that we can “just” do whatever they ask for.

Maybe it has something to do with how invisible software is to the tech-illiterate person but I’m not convinced. I’m sure there are other professions that get similar treatment.

But if they had such strict access control they also had backups. Right? Right?!

I don’t think it’s just a you problem :)

I didn’t think so. I guess Reddit has conditioned me to not state my opinion without a disclaimer, lest someone wants to start arguing :D

Btw. I don’t think you’ll find ZSH more intuitive to program. While it is an awesome interactive shell, the scripting part is Bash taken to the extreme.

Thank you for the thorough write-up. I’m surprised the answer is a “(mostly) yes” (Betteridge’s law).

Will listen to it as soon as I have time.

Bash script. Not necessarily hard to understand but very unintuitive in my opinion. I’ve written so much bash script over the years and still have to look up how to do simple things like iterate over associative arrays or do basic string manipulation. Maybe it’s just a me problem though 🤷

Yeah, I don’t know the exact structure of your translation files but a deep merge of your fallback files and the requested locale file should be enough.

Obviously I don’t know your codebase but couldn’t you do something like the following?

function loadTranslations(locale) {
  const fallbackTranslations = require("/i18n/en.json");
  const translations = require(`/i18n/${locale}.json`);
  return {
     ...fallbackTranslations,
    ...translations
  };
}

I think I misunderstood your initial post (and definitely didn’t read it as carefully as I should have 😅).

Do I understand your correctly that your goal is a companion object for your arrays that simplifies access? Not a new data structure that you’d user instead of arrays? If so, most of my points are moot.

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.

If you don’t treat IDs as opaque values, this is true.

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.

I think my point is actually wrong (it was really late when I was writing my initial response). Performance would be O(n), since that’s the worst case scenario.

Anyways, I hope you could take something useful from my answer.

Happy hacking :D

I’m pretty sure I’ve been in your situation but haven’t created a dictionary/array hybrid.

Without any more details about your use case and situation, I can imagine a few pitfalls with your solution:

• Serialization might not behave as you would expect (JSON.stringify).
• 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).
• How do you distinguish between ID access and index access? ArrayLike([ {id: "1" }, { id: "2" } ])[1] returns { id: "2" }, how do you access { id: "1" } by ID?
• It’s harder to reason about access time of lookups. However, this might not be a concern of yours.
• It may cause confusion if you’re working with other developers.

That being said, unless you work in an environment where your code should be easily understandable by others, the best way to find out if this is a good idea or not, is to try :)

Me personally, I usually use an associateBy function, when I need a values-by-ID structure. Of course this is not as convenient to use as your approach, but it’s good enough for me.

// this WILL drop elements if key is not unique 
function associateBy(array, key) {
  return array.reduce((acc, el) => ({
    ...acc,
    [el[key]]: el
  }), {});
}

associateBy([
  {id: "foo"},
  {id: "bar"}
], "id").foo; // -> {id: "foo"}

Good luck!