Javascript questions which don't deserve their own thread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›3 »

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Hi guys, does anyone here have any advice on this question about dynamic routing in angularjs?

the long and short of it is that we're trying to pass information around between nested controllers via routing, but it doesn't appear to be working because ng-view has its own $scope.

http://stackoverflow.com/questions/19295904/dynamic-routing-with-dynamic-controllers-in-angularjs

Any tips are appreciated.

# ¿ Oct 10, 2013 13:44

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 10:11

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Xik posted:

I'm not sure which of the JS/Web dev threads to put this in, so here goes:

I'm looking for a minimal unit testing suite/framework. At the moment I'm still writing stuff that is manageable in a single file, wrapped within a single anonymous function. I'd really like it if I could just write a bunch of unit tests in another single file to test all the functions that don't rely on the DOM. Maybe pass both files (or just the test file) to a node.js cli tool. Then it runs the tests and poops out the test results to the console.

Basically, just change what I currently do:
code:
clear && jslint myapp.js
to:
code:
clear && jslint myapp.js && testtool myapp.js mytests.js
or something. My use case for JavaScript in the foreseeable future is small and simple. Mostly greasemonkey scripts or small single page "apps" using no external libraries. I would just like the extra confidence unit testing can give in some circumstances.

e: Welp, probably should have googled better before posting, maybe mocha is what I want?

It might be a bit of overkill for your current needs, but I have been extremely happy with a Karma/Jasmine combo.

# ¿ Mar 22, 2014 13:33

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Skandranon posted:

scope.thing3 would simply be assigned the value of "z"

My impression is that scope.thing3 would be assigned a function that, when called, returns the value of 'z'. & bindings create a function wrapper according to the documentation.

# ¿ Mar 24, 2016 00:02

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Skandranon posted:

I didn't talk about & binding because that would have just made things even more confusing, my example has thing3 bound with @. When using & binding, it is passing in a function that exists on the parent scope that can be called by the child. In this case, the function would have to be on the scope, called z(), and you'd have had to pass it as <dir thing3="z()"></dir>

Ach! Somehow that @ turned into a & in my reading, sorry. The & thing confused us for a bit recently, so I must have been oversensitive to scope binding notation.

Carry on

# ¿ Mar 25, 2016 10:36

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Batham posted:

After having used AngularJS 1.x for a year and a half, I thought I'd take a peek at AngularJS 2.x this weekend. After hearing that they said they wanted to make AngularJS have a lot smaller learning curve, I really wasn't expecting what AngularJS ended up being. To be more exact; it seem like all they might've gained by possibly lowering the learning curve they lost by the much heavier front-load.

Am I wrong when thinking this? A year and a half ago I got up and running with AngularJS 1.x in less than half an hour, while the setup for AngularJS 2.x is not only a lot longer, there's also a lot more that you need to know already or setup.

For me it's definitely been the same experience. The need for extra tools for things like transpiling the typescript, having to learn both TS and the new framework, and all the extra config files beyond package and babel .Jason really make it harder to get up and running or change something about your workflow. Plus the angular 2 docs are even worse than those for 1 so that doesn't help.

# ¿ Oct 31, 2016 14:28

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

I think it's also worth nothing that because your client variable isn't explicitly declared as a var, it is actually a global and won't be GC'ed at all.

# ¿ Jan 26, 2017 23:41

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Dominoes posted:

Still same error.

I appreciate all the help you guys have been giving me with my noob questions. I'm not having any issues with the code itself or making my program work, but I'm struggling with the ecosystem.

I think you still need to import the types from lodash explicitly. See first answer here: http://stackoverflow.com/questions/34660265/importing-lodash-into-angular2-typescript-application

# ¿ Apr 2, 2017 14:14

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Dominoes posted:

Love it. Now I've ran into a module I think I need (a react drag+drop to replace the jquery one I'm using) that appears to be usable by import or require. (Only an NPM package; no .js script) Any tips for getting import working? I looked through the create-react-app folder, but I don't know what I'm looking for re: imports. Same "Uncaught ReferenceError: exports is not defined" error as before.

I think it depends a bit on the stack you're using, but if you're on something starting from create-react-app, doing npm install and then importing it should work, see https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#installing-a-dependency.

Is your tryout on github somewhere? Easiest way to nitpick.

# ¿ Apr 3, 2017 21:12

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Thermopyle posted:

People hate on JS (and sure its got a lot of bad stuff to it), but the tools are available to make it fairly pleasant to code in.

Next to clojure, after including lodash js is by far my favourite to do basically any kind of data transformation in. There's a very cool functional language hiding in all the weird poo poo.

I mean, this:

The good parts are pretty good.

# ¿ Apr 6, 2017 10:12

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Also, js object keys are essentially a set so you could just use that property if all you care about is string uniqueness.

# ¿ Aug 24, 2017 20:08

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Thermopyle posted:

https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore

I really would not like to give up lodash's matcher shorthands. They're super nice once you're used to them, especially the matchesProperty ones.

code:

var users = [
  { 'user': 'barney',  'age': 36, 'active': true },
  { 'user': 'fred',    'age': 40, 'active': false },
  { 'user': 'pebbles', 'age': 1,  'active': true }
];
 
_.find(users, function(o) { return o.age < 40; });
// => object for 'barney'
 
// The `_.matches` iteratee shorthand.
_.find(users, { 'age': 1, 'active': true });
// => object for 'pebbles'
 
// The `_.matchesProperty` iteratee shorthand.
_.find(users, ['active', false]);
// => object for 'fred'

# ¿ Sep 5, 2017 13:23

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Dogcow posted:

But.. if you use ES6 syntax the native array filter method is actually shorter in most of your examples

[...]

Plus it's native so it's going to be the fastest implementation unless the browser is complete garbage somehow.

You're right, but I was not taking ES6 into account. We're not doing transpile stuff at the moment. The nice thing about lodash is that it lets you do all this stuff without worrying about which browser/platform you're targeting too much.

Performance-wise, lodash beats native in quite a few cases last I checked, though that's besides the point most of the time.

# ¿ Sep 6, 2017 09:39

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Heads up for those still using bower: they are advising you to gtfo.

# ¿ Oct 6, 2017 14:42

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Tough luck indeed. The easiest way to do such things is, as stated, to just have two instances of the world, one for the current point in time, and one for the next time step, which is generated one cell at a time based on the current world.

Then overwrite the current time step's world with the future one.

# ¿ Mar 6, 2018 14:59

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Dumb Lowtax posted:

Regarding my other post, I guess there might not be too many WebGL people on board who target iOS. I think I might start breaking the code behind my URL above soon (to try to see what triggers the error) if no one else who might know the answer will be needing to see it anymore.

My eyes just start kind of glazing over at that layout, sorry.

# ¿ Apr 12, 2018 10:55

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Roadie posted:

Are there any dumb, hacky ways to dynamically register a component in Angular 1 without declaring a module? I'm converting an existing codebase to use a Webpack build and explicit imports for everything, and I've got AppHeader and AppNavigation components that I want to use in an App component without either (a) doing angular.module(APP_MODULE_NAME).component(...) inside the files (it would probably break stuff anyway given import hoisting) or (b) exporting them multiple layers down and having every single component I want to use declared in a root index.js.

Edit: Maybe some way to nest routes with ngRoute or ui-router so I can have all the generic stuff populate off /? I find it bizarre that none of the route stuff requires explicitly pre-registered components/directives when everything else does.

Edit edit: I really just want some straightforward way to attach more components to a root-level App component, though, so I can use <whatever-component></whatever-component> tags in the template files without polluting other areas of the code.

In angular 1 it's directives, not components, right? You just register those on your app's main module call with .directive. Either define them as part of the call or require them.

# ¿ May 10, 2018 11:58

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

porksmash posted:

This was two pages ago, but I had a go at it and I'd appreciate anyone that has more than 5 minutes of FP experience telling me how wrong I did it.

https://github.com/PeteAndersen/swarfarm-fe/commit/4ee5163c8ef18f4dcfb0badf8909dfd225706aab#diff-b32ad6e35f8970e39184af22c965237b

In short, the code is supposed to allow me to filter an array of a couple thousand objects based on my Redux state, which describes various filters. The filters can run against any object key or sub-object (of which there are a couple). The code transforms those filters into functions, runs them against a given array of objects, and returns the resulting list that pass all the filters. There's an example filter state representation in comments at the bottom of the linked code file. The objects it is running against are here: https://swarfarm.com/api/v2/monsters/

Thanks to Roadie for pointing me at FP, it's been a .... fun learning experience.

Looks fine! I think I'd use _.pick over

code:

filters.map(filter => get_filter_func(filter));

- in general if you're going from keysets to valuesets that saves a bunch of effort.

# ¿ May 18, 2018 12:04

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

In case of lodash you can also use the lazy evaluation chain which could help a lot. But yeah, when in doubt profile.

# ¿ Jul 17, 2018 07:06

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

FSMC posted:

I have quite a few functions that go through the DOM, extracts bits and changes bits, so I want to test the key functionality of my code. It will be running over a variety of x/html files, some that use various standards, ignore standards and do things in completely different ways. I think my issue is there is no way I'll ever get anywhere near being able to write good mock functions to emulate these functions acting on these html files. Why can't I test the actual functions acting on a html file?

Here is an example where "nodes = document.body.getElementsByTagName(elementCases[j]);" is giving me result I wasn't expecting. I don't know how I would mock this or what a mock should output. It seems like there should be a way to tests my functions on a test html file.

I may be missing something, but in general, I would
1) separate out any direct interaction with the dom to a separate service/library, and test that using something like jsdom
2) use pure functions as much as possible so it's easy to unit test.
3) use a linter; you have a missing var in the elementCases creation and nodes creation lines. This can bite you in the rear end because without 'var' you're creating a global. In general enable strict mode.
3) Try to have your code only do one thing. I find your function relatively difficult to understand because there's a lot of stuff interweaving. The presence of the IXBRL_ELEMENTS constant seems redundant since it's only really used as an argument to getCases(), and you could preserve the required tag on the getCases output if it returns an array of objects instead of just strings.

Is it the case that nodes[k].name is equal to elementCases[j]? If so you could greatly simplify things.

In general I would advise looking into lodash for some very handy tools to manipulate/transform data and objects.

# ¿ Sep 4, 2018 09:19

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

FSMC posted:

This is what I'm struggling to do. I've spent at least an hour a day for the last week trying to get somewhere but I'm just going round in circles. Either I find a comment that says don't do any DOM testing or it's easy just use jest, jasmine, jsdom, jquery, etc. I haven't found a single example I can use. I've tried following various examples but then they will be missing the main bits I need help with, e.g. it'll say "now you just write the tests like normal".

Lets use a really simple example. Say I want to test the following function on say google.com to see if it returns "google". I'm using vscode, I've used npm to install jsdom and jasmine and written a function. Now what?
code:
function getDocumentTitle(){
return document.head.getElementsByTagName("title")[0].innerText;
}

In principle I would say you want to do as little direct interaction with the DOM as possible in your logic, and abstract that away. One of the shallowest versions is something like:

code:

describe('the dom service', function() {
  it('should get the title', function() {
    var mockDom = new JSDOM(`<!DOCTYPE html><head><title>Hello world</title></head>`);
    var result = DomService.getDocumentTitle(mockDom.window.document);
    expect(result).toEqual('Hello world');
  });
});

Note that I'm forced to pass the window.document into the service in order to mock it. Using dependency injection and injecting the window.document instead would let me avoid having to pass it in.

Taking a step back, I'm also kind of curious why your data model is coming from HTML in the first place. There's probably easier-to-deal-with formats.

quote:

I'm a bit confused here, can you explain this in a way a noob like me would understand? I don't know what "required tag" means, or why I would return an array of object instead of strings.

What I meant is if getCases(IXBRL_ELEMENTS[i]) returns, instead of the array of cases, an object like :

code:

{
    ixbrlElement: 'ix:denominator,
   cases: ['foo', 'bar', 'qux']
}

you no longer need to refer to the IXBRL_ELEMENTS further in the function where you're assigning the value in the elements object. See below where I assume this is the case. I've spent some time noodling with your function trying to flatten the complexity out a bit but without more knowledge of your domain it's not going to go very far. See what you think:

code:

function getIxbrlElements() {
  return IXBRL_ELEMENTS
      .map(getCases)
      .reduce(function(elements, elementCases) {
        elements[elementCases.ixbrlElement] = elementCases.cases.reduce(getNodes, {});
        return elements;
      }, {});
}

function getNodes(value, elementCase) {
  var nodes = DomService.getTagElements(elementCase);
  // if using lodash this for loop can be written as
  //   _.zipObject(_.map(nodes, 'name'), nodes.map(nodeToObject));
  for (var k = 0; k < nodes.length; k++) {
    value[nodes[k].name] = nodeToObject(nodes[k]);
  }
  return value;
}

I've steered clear of getting too ES6-y so no arrow functions or consts.

# ¿ Sep 10, 2018 22:31

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

FSMC posted:

Thanks. I managed to get jsdom working both with with a mock and then also got it working with a site by adding some code from https://github.com/dnajs/load-web-page-jsdom-jasmine. I had some trouble with jsdom at first sine it doesn't seem to support any of the dom manipulation functions I use.

Mostly people run jasmine tests using Karma, which I see below you're moving towards. Karma is not a jsdom replacement, but a test runner, so you still need to load jsdom if you want to use it as your browser: https://www.npmjs.com/package/karma-jsdom-launcher . Karma does manage the part you're asking about regarding aggregating the test files to load, plus can do a whole bunch of other stuff like coverage reports.

If the DOM manipulation you use is not supported by jsdom you're probably best off using a browser, probably headless chrome since Phantomjs is no longer being worked on.

quote:

There are two use cases why want good html coverage and why data is in the html in the first place. The first is sets of accounts in ixbrl format stored as xhtml, so I need to test anything built over a variety of accounts created using various software. The second is I'm working on an extension that does it's magic by getting and adding data to different sites I have no control over, if I fix something on one site I want tests to make sure I haven't broken it on another site, etc.

So you're testing against live sites? That does complicate matters. I'd still advise for the unit tests at least to try and separate dom manipulation and actual logic as much as possible so you have only one thing to worry about (like css selectors vs loop corner cases or whatever).

Good luck.

# ¿ Sep 14, 2018 08:25

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

In general I've found that using 'this' is mostly unnecessary and confusing. Arrow functions only made it worse (except if you were already avoiding 'this' in the first place).

# ¿ Nov 12, 2018 12:30

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Joda posted:

In what world did arrow functions make it worse. They make sure that the lambda captures this in the only way that makes sense (e.g. if we're in a class, this refers to the object)

By adding to the mental load of remembering how the this keywords works in every context. I agree that functionally the way this in arrows works is useful, I could have phrased that more clearly, sorry.

# ¿ Nov 12, 2018 13:42

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Tea Bone posted:

I'm pulling my hair out over this.

I have a selection box, depending on it's selection it should make the input in a following div disabled.

html:
code:
<select class="my-selection">
	<option value="1">One</option>
	<option value="2">Two</option>
</select>
<div class="input-container">
	<input type='text'>
</div>
Then the java script:
code:
$('body').on('change','.my-selection',function(e){
        if ($(this).val() === '2'){
            var content= $(this).nextAll('.input-container').first();
	    foo = content.find('input')
            content.find('input').prop('disabled', true);
        }
    });
For the life of me I can't get it to work. I can call .hide() on the input and it works and the really odd thing is, if I run foo.prop('disabled', true) from the console the input disables as expected. I'm guessing I've misunderstood how find/nextAll work.

Works for me https://jsfiddle.net/voa2jmeq/

# ¿ Nov 13, 2018 15:14

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Nolgthorn posted:

Met somebody once, I was conducting their interview, and they wrote all of their loops in reverse.
code:
for (let i = 10; i >= 0; i--)
So I asked him why he was doing that, he said it was more performant.

Anyone who claims to care about performance that much and then uses postfix in/decrement is just weird to me.

The widespread use of postfix operators where the cached value is irrelevant is just so irritating to me (and yeah I know it will usually get compiled into prefix but ugh. Write what you mean).

# ¿ Dec 3, 2018 10:57

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Doom Mathematic posted:

Are you saying prefix increment/decrement is faster than postfix increment/decrement in that context?

Probably not in that context, as I tried to explain with the bit about the compiler. It's just that I'd expect someone who is being anal about performance to not risk it.

# ¿ Dec 4, 2018 13:42

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

I think you're looking for uniqWith? The _.isEqual example should work.

e: if I was writing it myself I'd probably base it on an object with hashed indices, like so:

code:

function hash(val) {
  return val.join(','); 
}

function dedupeTuple(arr) {
  var itemsByHash = _.reduce(arr, (accum, item) => {
    accum[hash(item)] = item;
    return accum;
  }, {});
  return _.values(itemsByHash);
}

You can make the accum write conditional but I can't think of a reason reason to.

Osmosisch fucked around with this message at 12:19 on Jan 22, 2019

# ¿ Jan 22, 2019 12:07

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Yeah, that's the same solution as I posted a bit upthread, though I lean on lodash (I prefer to let one library handle all the browser compatibility stuff vs. shim/transpile).

e: I did some jsbenching, looks like for 10k elements the hash version is about 100x faster, with the native reduce and Object.values() faster than lodash's version.

https://jsbench.me/7qjr7x9o5c/1

The if statement does not appear to have significant impact.

Osmosisch fucked around with this message at 16:37 on Jan 22, 2019

# ¿ Jan 22, 2019 15:32

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Nolgthorn posted:

Is jsperf broken or something, yesterday it told me using lodash was fastest too.

There's a bunch of variance there since all the benchmarks are running in your browser. So for example if you (or some background process) are doing poo poo in another tab during one of the tests it will gently caress with the results. Or a garbage collection is triggered, or any of tons of other possibilities.

e: added the galaxy brain solution, it's on my machine about 25% below hashbased which is not surprising given that JSON.parse isn't exactly a free operation.

Osmosisch fucked around with this message at 11:58 on Jan 23, 2019

# ¿ Jan 23, 2019 11:53

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Jabor posted:

Hmm, you seem to be putting a lot of effort into this cloning code to fix up all the edge cases you run into. Maybe you should make it a library so that you only need to do it once instead of repeating it on every single project?

This discussion has been such a beautiful slow burn.

# ¿ Feb 5, 2019 14:28

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Wait, you're editing your js in Chrome? Why would one do that?

# ¿ Feb 19, 2019 09:57

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Dumb Lowtax posted:

Why wouldn't I?

Well, you've demonstrated at least one reason so far in this very thread.

I don't recall recommending Babel generally over ES6. I'd be inclined to do the opposite unless you have to serve a wide array of browsers.

# ¿ Feb 19, 2019 13:41

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

evilfunkyogi posted:

I very genuinely do not mean to "you're doing it wrong" but this:

is not what the es6 module API was designed for.

Yeah, if you want people to look at code why not just give them the code? Have them browse it in an IDE or on github or whatever.

# ¿ Mar 18, 2019 11:06

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

mystes posted:

I guess you had better tell that to every language that has a way to generate html documentation/code listings?

Documentation is not what's being discussed.

If a language has the feature of generating html listings, more power to it. I'd call that wasted effort in the current ecosystem, but whatever. It's also not what Dumb Lowtax is asking about, unless I've completely misunderstood what's going on here (always entirely possible).

# ¿ Mar 18, 2019 15:12

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

I share the concerns above.

I'm still kind of lost why all this effort is going into a code browser when that's basically a solved problem. Like, git clone or unzip -> open in vscode, done. Including clickable import source links.

# ¿ Mar 20, 2019 00:14

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Bruegels Fuckbooks posted:

if i had to build every time i did console.log i'd go insane.

Webpack can do partial rebuilds and hot reloading making this not an issue, thankfully.

I mean, you're not wrong, but at least there's bright points.

# ¿ Mar 27, 2019 18:41

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Being so spoiled by idea and chrome debuggers, doing a bunch of clojure on the side with its REPL plus lack of debugger has been really educational. It's especially brought me back to testing practically every line of code rather than going 'eh it's just controller boilerplate.' Small functions and tests let you sniff out bugs with a couple of prints.

# ¿ Mar 27, 2019 19:46

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Dumb Lowtax posted:

I learned es6 and for three years have never imported any JavaScript libraries, needed outside code, or used a compilation tool. That hasn't stopped me from making anything I've wanted yet. It's overall been a very rewarding and non-frustrating experience

To be fair you do post a lot of questions that basically boil down to "help me reinvent this round rolly thing please" but not gonna lie it's fun to watch.

# ¿ Mar 28, 2019 11:59

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

darthbob88 posted:

It doesn't, though. If I delete the lockfile, npm just creates a new one, which still points to the public registry for those packages. If I go through and replace all the references to public registry with the private one, it just overwrites them with references to the public one. It's maddening.

Are your private dependencies scoped?

# ¿ Mar 29, 2019 22:13

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 10:11

Osmosisch: Sep 9, 2007; I shall make everyone look like me! Then when they trick each other, they will say "oh that Coyote, he is the smartest one, he can even trick the great Coyote."; Grimey Drawer

Dumb Lowtax posted:

Yeah at this point it's obvious that I should have gone with that, I even tell them that it's probably better for all purposes. Next time. For now I ran out of preparation time before school started and didn't get to try it myself.

This is great to read, I was worried you would keep going down this rabbit hole. Kudos, hope the class goes well.

# ¿ Apr 8, 2019 08:04

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

«‹›3 »