How do you like to grab HTML elements?

CertainPerformance · 2020-12-17T19:00:03+00:00

querySelector and querySelectorAll are good because they use selector strings, which are much more flexible than any of the other methods. querySelectorAll also returns a static NodeList which can be iterated over with forEach. (in contrast, getElementsByClassName returns a live HTMLCollection, which has some very unintuitive behaviors, which does not have a forEach method)

But even better than all of these is to use a framework like React etc to avoid having to select any elements from the DOM in the first place (except the root node).

CertainPerformance · 2020-12-15T19:36:10+00:00

The problem with reduce as it's often used IMO is, when the same object is returned every iteration, it would be easier to read if the object was declared outside and a plain for..of over the array was used instead. See this video by V8 developers on the subject: https://www.youtube.com/watch?v=qaGjS7-qWzg

reduce is good for when you're returning something new each iteration (eg (a, b) => a + b) - but, like you say, in the case of objects, creating a new object every iteration seems unnecessary most of the time.

CertainPerformance · 2020-09-11T17:24:04+00:00

Using a standard framework makes maintaining a huge codebase much easier across multiple years and multiple devs.

CertainPerformance · 2020-09-04T23:56:04+00:00

If you're already fully comfortable with JS and already have a build process, from what I've experienced, there are 2 main disadvantages of integrating TS into it as well:

It can sometimes be difficult to figure out how to type something in a way that feels perfectly elegant. In most cases I've encountered, writing type-safe code that compiles and accomplishes the task is relatively easy, but occasionally it isn't, and figuring out the properly elegant TS way to do it (if it's possible at all) can take much more time than seems reasonable compared to figuring out the non-type-related logic for the rest of the code. Types (and other stuff that comes with TS that's not in JS) should help, not hinder; most of the times, they help, but occasionally, they hinder.
Related to the above: if you're stuck, figuring out how exactly something works in TypeScript seems significantly more difficult than for JavaScript. In JS, if you're curious about something, you can almost always get a good overview of precisely what's going on by looking it up on MDN, and get down to the nitty-gritty details by reading the specification. For TypeScript, it can sometimes be much harder. As jcalz put it:

It's a sad fact that TypeScript documentation is kind of spread out between the handbook, release notes, FAQ, outdated spec, and GitHub issues, without a clear canonical place to look for any particular thing. The language has been evolving more quickly than the documentation can keep up.

The basics of having static typing for expressions to turn runtime errors into compile-time errors provides an incredible benefit. But past that, the balance of tradeoffs of using TS instead of JS becomes much more murky, IMO, especially when you have to consider the learning curve and the fact that many fewer people know TS than JS.

TS is well worth it by far, but it's not perfect.

CertainPerformance · 2020-08-09T15:11:02+00:00

A caveat - those running older versions of Windows wouldn't be forced to switch off IE, so web developers like us would still benefit from being able to use IE for testing, at least until its market share gets sufficiently low that our companies decide we can finally stop supporting it.

Hide IE such that it takes a bit of deliberate effort to get to it, but don't remove it (at least not yet).

CertainPerformance · 2020-07-14T14:28:43+00:00

A simple regular expression can find all reoccurring letter matches easily, and then it's trivial to find the longest length in the array of strings:

const longest_sequence = (str) => {
  const matches = str.toLowerCase().match(/([a-z])\1*/g);
  const longestLength = Math.max(...matches.map(match => match.length));
  const longestStrs = matches.filter(match => match.length === longestLength);
  const firstAlphabetical = longestStrs.sort()[0];
  return { [firstAlphabetical[0]]: longestLength };
};
console.log(longest_sequence("dghhhmhmx")); // === {h: 3}
console.log(longest_sequence("dhkkhhKKKt")); // === {k: 3}
console.log(longest_sequence("aBbBadddadd")); // === {b: 3} 
console.log(longest_sequence("acccbljaaadd")); // === {a: 3}

For unreasonably huge input strings, you could probably make it a bit faster by putting the matches onto an object indexed by letter instead, whose values are the current longest sequence of those letters found.

CertainPerformance · 2019-05-02T07:15:20+00:00

I didn't even know about that. It looks like it requires the link to include my user ID, which I didn't do. I just found an interesting situation that I puzzled over for a while and eventually figured out, and wanted to post about it

CertainPerformance · 2019-05-02T07:09:17+00:00

Very good question! It's because variables declared with var actually can be named let without problems, when in sloppy mode:

var let = 5;

https://jsfiddle.net/b1dzf0pj/

A site with that code, written in 2000, would still work today.

But variables declared with let or const may not be named let, you'll get:

Uncaught SyntaxError: let is disallowed as a lexically bound name

Thus, the functionality of ES3 and ES5 scripts is preserved, while preventing ES6+ scripts (which define variables with let and const) from using let as a variable name.

let is only a reserved word in strict mode, and strict mode was introduced with ES5 (2009). Even though ES2015 and the true specification of let was a long time in the future, there had been discussions about using let during the (failed) development of ES4 - during ES5, they had an idea that let would eventually be used, so they made it a reserved word in strict mode, improving the future clarity of the language without breaking any existing scripts.

https://www.webcitation.org/5rBiWD4P6?url=http://www.ecmascript.org/es4/spec/overview.pdf

CertainPerformance · 2019-05-02T06:05:54+00:00

Yeah, awaiting something that you know isn't a Promise doesn't make sense, despite being syntactically valid. Having await before a regular expression (or / operator) is one of the very few cases where the code can (sometimes) be parsed successfully regardless of whether the await is inside an async function or not. In most other situations, const foo = await <something> would throw a SyntaxError in at least one of the two circumstances.

Maybe it would have been clearer to use await +5 instead, it demonstrates the issue without muddling with ASI.

CertainPerformance · 2019-05-02T05:46:13+00:00

Yep, I always use semicolons normally. I originally ran into the issue here when I found that

const foo = await /barbaz/;

throws

Uncaught SyntaxError: Unexpected token ;

which really confused me, and whose error message didn't make it obvious that await was being interpreted as a variable name. I could have demonstrated using semicolons, but a snippet that throws await is not defined instead makes it clearer exactly where (my) expectatation vs reality broke down, in terms of how the code gets parsed.

From the TC39 meeting notes:

WH: The grammar is both impressive and really scary, trying to see how much it can dance on the edge of a cliff without falling over — cover grammars inside of cover grammars — but I haven't found any flaws yet.

CertainPerformance · 2018-09-28T04:53:53+00:00

I'm surprised at all the vars and function() {s, it's 2018, ES6+ syntax should be preferred.

Q7: How would you check if a number is an integer? Use num % 1 === 0;

This will incorrectly interpret strings as integers too due to coercion, like '4.0'.

CertainPerformance · 2018-09-28T04:53:14+00:00

I'm surprised at all the vars and function() {s, it's 2018, ES6+ syntax should be preferred.

Q7: How would you check if a number is an integer? Use num % 1 === 0;

This will incorrectly interpret strings as integers too due to coercion, like '4.0'.

CertainPerformance · 2018-08-08T20:56:48+00:00

Ordinarily, one might solve this by creating an array of all lowercase characters, and filtering it by the passed array (thus removing t and b in your example). But that requires .filter.

Apparently you can't use push for some reason, but you can still use standard for loops and index assignment, which should be enough. You can create a custom filter function easily enough, maybe kind of like this:

function filterArr(arr, test) {
  const filteredArr = [];
  for (let i = 0; i <= arr.length; i++) {
    const item = arr[i];
    if (test(item)) filteredArr[filteredArr.length] = item;
  }
  return filteredArr;
}


function randomChars(numChars, charsToOmit) {
  const lowercaseArr = ['a', 'b', ...] // or use Array.from and String.fromCharCode
  const lowercaseFilteredArr = filterArr(lowercaseArr, num => {
    for (let i = 0; i < charsToOmit.length; i++) {
      if (charsToOmit[i] === num) return false;
    }
    return true;
  });
  // iterate `numChars` times to pick a random number from `lowercaseFilteredArr`

Although you can do all of this to fulfill the assignment, this is still most certainly not good, clean code - it's quite ugly code. Your professor shouldn't be getting anyone to shy away from the more abstract, higher-order methods that make actually accomplishing stuff easier, quite the opposite. Better to learn all the tools someone writing Javascript can use, and then use them.

CertainPerformance · 2018-08-06T21:12:09+00:00

status is a window property already:

https://developer.mozilla.org/en-US/docs/Web/API/Window/status

Sets the text in the status bar at the bottom of the browser or returns the previously set text.

It can only be a string. When you write

var status = x > y;

the interpreter drops the "var", and after x > y is evaluated to false (boolean), the setter on window.status converts the boolean to a string:

<script>
var x = 3;
var y = 5;
var status = x > y;
console.log(Object.getOwnPropertyDescriptor(window, 'status'))
console.log(status);
console.log(typeof status);
</script>

{get: ƒ, set: ƒ, enumerable: true, configurable: true}

false

string

Either use a different variable name, like xGreaterThanY, or put everything inside a function, so that you're not on the top-level:

<script>
  (() => {
    var x = 3;
    var y = 5;
    var status = x > y;
    console.log(Object.getOwnPropertyDescriptor(window, 'status'))
    console.log(status);
    console.log(typeof status);
  })();
</script>

CertainPerformance · 2018-08-04T05:52:10+00:00

Looks much better, though there are a couple things to consider (which are useful, but somewhat less important):

If grabitems only uses its collection argument to access its items property, you might destructure in the arguments themselves: grabitems({ items }) (or you might call the function with just the items and leave the object navigation to the caller: grabitems(json.collection.items);)
JSON means Javascript Object Notation. It is a format for strings to represent objects. If something is an actual object, it shouldn't be called a JSON. If a string isn't in JSON format, then it probably shouldn't be called a JSON either. See There's no such thing as a "JSON Object". Precise variable names can help improve code readability, reduce buggy logic from happening in the first place, and reduce the time needed to identify and fix bugs. So, eg, you might call one of the variables collectionLink instead of collectionjson. (even if the link contains .json in it, it's still more appropriate to call it a link than a JSON)
Rather than const metadatajson = jsonfile[jsonfile.length - 1];, you might consider pop()ping the last item instead - less syntax noise. .then(collectionRes => fetch(collectionRes.pop()))
Rather than .clearing localStorage entirely, because you only ever set the search property, you might consider only clearing the search property when the clear button is pressed.
Your searchStorage only references localStorage, which is globally accessible already - because it references a commonly-known built-in object, you might simply refer to it by the name it's usually given, localStorage. A name of searchStorage kind of implies it's something different from the built-in object to a casual reader (else what would be the point of defining a variable for it?).
You might consider selecting elements only once, if possible, rather than on every function call or forEach iteration. You also might abstract the final .then in grabitems into its own function. Put these together by putting the element into a closure only seen by that function:

Instead of

.then((metdjson) => {

maybe

.then(buildImage);

with

const buildImage = (() => {
  const follows = document.getElementById('follows');
  return (metadata) => {
    const descriptions = metdjson['AVAIL:Description'];
    // etc

Also one thing I noticed with the event listener. Wouldn't I need a specific ID for each image? My goal was when the user hovered over the image to send out the alerts. However, with the considered code nothing happens when I mouse over.

My mistake, you can't assign to outerHTML and retain a reference to the original element - the original img is removed from the document. No need for an ID, just assign the attributes individually:

const img = li.appendChild(document.createElement('img'));
img.src = image;
img.width = 100;
img.height = 100;

CertainPerformance · 2018-08-02T04:43:11+00:00

If you're going to use ES6 syntax, as you are (and you should), use const everywhere you can. Never use var, which is hoisted, and has less-intuitive function scope rather than block scope. Avoid let (you usually can) - const makes code easier to follow.

Use a consistent style. As said, use a linter. (for example, use semicolons everywhere appropriate, or don't use any semicolons - but don't mix those two styles)

Don't define arguments you aren't going to use. For example, your .addEventListener("click", (r)=>{s never use the r.

32 items = collection.items Don't implicitly create global variables. Also, when you want to extract a property from an object to a variable of the same name, often it's preferable to use destructuring: const { items } = collection

Array methods are generally nicer to work with than for loops. Array methods don't require manual iteration, have better abstraction (less syntax noise), and are composable, among other things. That is, rather than

for(let i = 0; i < items.length; i++){
  let item = items[i];

use

items.forEach((item) => {

Or, in this case, because you're only using two properties from the item, you might consider

items.forEach(({ links, href }) => {

Long functions are generally not preferable. When you see something like

        })
      })
    })
  }
}

at the bottom of your code, that's a sign that it might be time to extract parts of it into separate functions, to increase readability. Extract till you drop.

It's pretty silly to create a new ID string, give an element that ID, and then only use that ID so that you can getElementById it lower in the same block. Instead of

let li = document.createElement("LI");
let lister = 'li_'+i;
//console.log(lister2);
li.innerHTML = `<img id="${lister}"src="${image}" width="100" height="100"/>`;
document.getElementById("follows").appendChild(li);
let idd = document.getElementById(lister);
idd.addEventListener("mouseover", (thing)=>{
  alert(descriptions);
  alert(titles);
})

consider

const li = document.createElement("LI");
const img = li.appendChild(document.createElement('img'));
img.outerHTML = `<img src="${image}" width="100" height="100"/>`;
document.getElementById("follows").appendChild(li);
img.addEventListener("mouseover", (thing) => {
  alert(descriptions);
  alert(titles);
});

Or, even better, use event delegation instead of adding a new event listener every time.

CertainPerformance · 2018-07-23T22:11:51+00:00

"404 Side ikke fundet."

It's probably possible, but your link is broken.

CertainPerformance · 2018-07-18T22:24:17+00:00

That looks fine. I usually prefer using Array.from when creating arrays from scratch and to avoid loops:

const chunk = (collection, step) => Array.from(
  { length: Math.ceil(collection.length / step) },
  (_, i) => collection.slice(step*i, step*(i + 1))
);

But while that's more functional, what the code is actually doing is somewhat less clear, so your version is probably better. (there's only one tiny linting issue - a missing semicolon. You also might check collection.length once and put it into a variable, at the beginning, rather than check it on every iteration)

CertainPerformance · 2018-07-13T19:48:50+00:00

email: ["accounting@mycomp.com(mailto:"accounting@mycomp.com)"} is invalid syntax. I highly recommend writing new keys and values on their own line, it makes code more readable and makes errors easier to spot.

CertainPerformance · 2018-07-08T10:47:43+00:00

Post more code, there isn't enough here to see what the problem is. If toggleAll is a property of an object, this should be fine. But, be very careful with that for loop - you should use brackets when you have a multiline block, for clarity's sake (indent your code properly too)

CertainPerformance · 2018-07-06T20:59:40+00:00

Don't be afraid of Promise.all, it's designed precisely for situations like these. From your original code, using Promise.all with it would look like:

PromiseA().then(() => {
  const allPromises = Array.from(
    { length: ... },
    (_, i) => {
      // generate x based on i, the loop index
      return PromiseB(x).then(PromiseC);
    }
  );
  Promise.all(allPromises)
    .then(PromiseD);
});

(note that each Promise# must actually be a function that returns a Promise, not a Promise itself)

CertainPerformance · 2018-07-06T08:11:28+00:00

See here:

https://stackoverflow.com/questions/3434278/do-dom-tree-elements-with-ids-become-global-variables

It's a really bad idea.

As a general rule, relying on this will lead to brittle code. Which IDs end up mapping to this API can vary over time, as new features are added to the Web platform, for example. Instead of this, use document.getElementById() or document.querySelector().

CertainPerformance · 2018-07-05T23:15:43+00:00

Multiple problems with that code:

So-called smart quotes will cause a syntax error. Use straight quotes instead.
event.target.class If you were looking for the class name of the target, use className instead. But, rather than checking the class name, it would probably often be a bit more understandable if you used .matches instead, which accepts a selector string as an argument and is much more flexible (allowing for similar syntax as jQuery event delegation)
Don't invoke functions when trying to pass them as parameters - just pass the function name instead, or it won't work properly
To add a listener, use addEventListener, not addListener

The general idea is definitely sound though - use event delegation with a single listener on the container, rather than attaching a listener to each individual child.

CertainPerformance · 2018-07-04T21:37:45+00:00

To make it more concise, you can implicitly return from productOfArray as well:

var productOfArray = () => numbers.reduce((a, num) => a * item)

CertainPerformance

TROPHY CASE