Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Munkeymon
Aug 14, 2003

Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.



Just use inline-block wrappers for low-effort horizontal flexbox emulation :v:

'just stick an i-block on it' is pretty much my 'put a bird on it'

Adbot
ADBOT LOVES YOU

Rubellavator
Aug 16, 2007

Something somewhere is failing silently and it doesnt make sense and it only occurs in ie and i want to cry.

Plavski
Feb 1, 2006

I could be a revolutionary
Thanks to Microsoft's reduction in security updates and support, we now only have to go back as far as IE11. That still doesn't stop us from having to polyfill Promises and fetch :argh:

Could be worse tho, as we had to support IE8 and IE7 via compatibility mode in the previous application :suicide: So IE11 is positively bleeding edge compared to our usual fare.

Sistergodiva
Jan 3, 2006

I'm like you,
I have no shame.

Ok, so it's probably something really stupid I am missing. But I can't get ng-click to fire at all using angular-ui-bootstrap with angular.

I have spent hours trying to get this to work.

Even if I put a simple console.log inside it that won't fire.

I managed to get one button working by wrapping it inside a <a ng-href=""></a> but that's it.

Anyone have any idea what I am doing wrong?

https://www.pastery.net/yjmhnz/


edit: here is a fiddle where I tried to reproduce it as much as possible.

https://jsfiddle.net/qp07vw1h/1/

Sistergodiva fucked around with this message at 02:32 on Mar 10, 2017

Skandranon
Sep 6, 2008
fucking stupid, dont listen to me

Sistergodiva posted:

Ok, so it's probably something really stupid I am missing. But I can't get ng-click to fire at all using angular-ui-bootstrap with angular.

I have spent hours trying to get this to work.

Even if I put a simple console.log inside it that won't fire.

I managed to get one button working by wrapping it inside a <a ng-href=""></a> but that's it.

Anyone have any idea what I am doing wrong?


Umm, it isn't obvious to me what you want in this fiddle? You are focusing on that dropdown button in top right?

One problem is your fiddle isn't even loading Angular.

Skandranon fucked around with this message at 05:17 on Mar 10, 2017

Sistergodiva
Jan 3, 2006

I'm like you,
I have no shame.

Skandranon posted:

Umm, it isn't obvious to me what you want in this fiddle? You are focusing on that dropdown button in top right?

One problem is your fiddle isn't even loading Angular.

https://jsfiddle.net/qp07vw1h/2/

I had it on settings for js library, added it menually now though.

What I am trying to do is just get the <button>s working at all. Currently ng-click is not triggering anything at all.

HaB
Jan 5, 2001

What are the odds?

Sistergodiva posted:

https://jsfiddle.net/qp07vw1h/2/

I had it on settings for js library, added it menually now though.

What I am trying to do is just get the <button>s working at all. Currently ng-click is not triggering anything at all.

Worked cranked up as soon as I walked in, so I haven't had time to look at this yet, but after a quick glance:

- your body tag is missing ng-app (fiddle may take care of that somewhere)
- stop using $scope.
- holy crap your typing style is ugly. camelCase things. Put spaces around = signs.
code:
$scope.button1={
    isopen: false
}
;

// is OPPRESSIVE.  Do this:

$scope.button1 = {
    isOpen: false
};
// your eyeballs and fellow devs will thank you

- read this: https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md
- read that again.
- one more time.

Vesi
Jan 12, 2005

pikachu looking at?
any reason you're not using angular2 since this doesn't seem like a legacy project?

Gildiss
Aug 24, 2010

Grimey Drawer

Vesi posted:

any reason you're not using angular2 since this doesn't seem like a legacy project?

Everything I've read about angular 2 sounds like a stability nightmare.

MrMoo
Sep 14, 2000

Gildiss posted:

Everything I've read about angular 2 sounds like a stability nightmare.

Isn't that just JS frameworks in general? They don't exactly have a long shelf life.

Meanwhile looks like Polymer 2 is starting to ship and defaulting to ES6 classes to define web components.

Gildiss
Aug 24, 2010

Grimey Drawer

MrMoo posted:

Isn't that just JS frameworks in general? They don't exactly have a long shelf life.

Meanwhile looks like Polymer 2 is starting to ship and defaulting to ES6 classes to define web components.

The only articles I had seen about Angular 2 were about breaking updates and the modules it depends upon not being stable either.
Now I just don't see anything about it.

So yes, business as usual for JS packages.

lunar detritus
May 6, 2009


Gildiss posted:

The only articles I had seen about Angular 2 were about breaking updates and the modules it depends upon not being stable either.
Now I just don't see anything about it.

So yes, business as usual for JS packages.

Angular 2's API was really unstable during their beta releases and RC but it has been like a rock for +6 months now.

Sistergodiva
Jan 3, 2006

I'm like you,
I have no shame.

HaB posted:

Worked cranked up as soon as I walked in, so I haven't had time to look at this yet, but after a quick glance:

- your body tag is missing ng-app (fiddle may take care of that somewhere)
- stop using $scope.
- holy crap your typing style is ugly. camelCase things. Put spaces around = signs.
code:
$scope.button1={
    isopen: false
}
;

// is OPPRESSIVE.  Do this:

$scope.button1 = {
    isOpen: false
};
// your eyeballs and fellow devs will thank you

- read this: https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md
- read that again.
- one more time.

Thanks. I am so used to intellij and java, I tried installing some plugins to help me with intellisense and stuff but they aren't really working that well.

Awesome with a style-guide, I will check that out.

Apparently it was the ng-controller not being set in index.html

I totally forgot about that, since all the templates get their controllers assigned from my routing.

This is a school project so I didn't really have a choice when it came to using 2.

Skandranon
Sep 6, 2008
fucking stupid, dont listen to me

Sistergodiva posted:

Thanks. I am so used to intellij and java, I tried installing some plugins to help me with intellisense and stuff but they aren't really working that well.

Awesome with a style-guide, I will check that out.

Apparently it was the ng-controller not being set in index.html

I totally forgot about that, since all the templates get their controllers assigned from my routing.

This is a school project so I didn't really have a choice when it came to using 2.

Ok, glad that part is over. Now let me tell you about TypeScript...

Vesi
Jan 12, 2005

pikachu looking at?

Sistergodiva posted:

Thanks. I am so used to intellij and java, I tried installing some plugins to help me with intellisense and stuff but they aren't really working that well.

Awesome with a style-guide, I will check that out.

Apparently it was the ng-controller not being set in index.html

I totally forgot about that, since all the templates get their controllers assigned from my routing.

This is a school project so I didn't really have a choice when it came to using 2.

at least in vscode you can turn on auto-formatting ("editor.formatOnSave": true), dunno about full visual studio, completion works well too

Sistergodiva
Jan 3, 2006

I'm like you,
I have no shame.

Skandranon posted:

Ok, glad that part is over. Now let me tell you about TypeScript...

Comming from java typescript sounds a lot more like my kind of thing. How compatible are they? Like, would I be shooting myself in the foot if I learned typscript instead of javascript? Should I learn javascript first and then focus more on typescript?

Maluco Marinero
Jan 18, 2001

Damn that's a
fine elephant.
You can't really learn Typescript without learning JavaScript, as Typescript is just a typed superset of JavaScript. Valid JavaScript is valid Typescript but without the types.

Plavski
Feb 1, 2006

I could be a revolutionary
Typescript is really great though and if you're gonna learn JavaScript, you really should learn typescript.

luchadornado
Oct 7, 2004

A boombox is not a toy!

Plavski posted:

Typescript is really great though and if you're gonna learn JavaScript, you really should learn typescript.

Quoted for truth. Designing by guarantee is one of the best ways to become a better programmer. Let your language/libraries/frameworks/tooling provide as many guarantees as possible so that you have less code to write, less brittle code that is written, and fewer tests to write.

Typescript is simply a compile-time (and writing-time if you have a modern editor like VS Code) guaranteed way of enforcing contracts, signatures, and shapes of the things you're passing around and using. It doesn't increase your production code size in any way. It's also completely opt-in - you can start by just making an interface for a single complex object that causes you headaches while everything else in your code is implicitly treated by the Typescript compiler as having type 'any'.

Typescript 2.1 was released in the last few months which adds support for async and object rest/spread, so it's feasible to completely ditch Babel for transpilation at this point if you're sick of how convoluted Babel has become and the breaking changes it introduces every year.

luchadornado fucked around with this message at 14:31 on Mar 11, 2017

luchadornado
Oct 7, 2004

A boombox is not a toy!

I also just switched from using redux-thunk and redux-saga in work/personal projects to using middleware. Atomic units of work like resolving a fetch promise, or chain of network calls where I only care about the end result, are handled purely in middleware. Any other type of scheduling is handled by the React component's lifecycle. My action creators and reducers are stupid, simple, and synchronous now.

Not only has it made things easier to test and maintain, but it just feels nice. Highly, highly recommended at least trying it out for anyone that has ever thought to themselves "updating state from async events sucks" - which is probably anyone that's ever built a React app, to be honest.

Kekekela
Oct 28, 2004

Helicity posted:

I also just switched from using redux-thunk and redux-saga in work/personal projects to using middleware.
Sorry for being dense but I don't think I'm following exactly what you're saying here. I thought redux-thunk was my middleware. :confused:

I want to try out whatever you're talking about though because I was honestly thinking of switching to sagas next, but I can infer from your post they have not been the silver bullet I was hoping for.

Helicity posted:

"updating state from async events sucks"
Yes this is playing on an infinite loop in my subconscious somewhere.

ModeSix
Mar 14, 2009

Vesi posted:

any reason you're not using angular2 since this doesn't seem like a legacy project?

I don't see how this question is really even a good question.

Angular 1 and Angular 2 are basically two almost completely different toolsets that accomplish more or less the same thing.

It's like asking someone why they're using React instead of Aurelia. Going from Angular 1 to 2 is not a straight upgrade path. Angular 2 is a completely different beast from 1.

Just my 2 cents worth on the topic.

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

I don't follow Angular well enough to know the answer to this question: How long will Angular 1 be getting updates?

It's very important to consider the future prospects for updates when choosing a library. Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web

Vesi
Jan 12, 2005

pikachu looking at?

ModeSix posted:

I don't see how this question is really even a good question.

Angular 1 and Angular 2 are basically two almost completely different toolsets that accomplish more or less the same thing.

It's like asking someone why they're using React instead of Aurelia. Going from Angular 1 to 2 is not a straight upgrade path. Angular 2 is a completely different beast from 1.

Just my 2 cents worth on the topic.

Yes it was more for myself, I just started a angular2 project and it's still not too late to change to something else. I do know google deprecates older versions quickly so I wouldn't consider angular1 anyway.

ModeSix
Mar 14, 2009

Vesi posted:

Yes it was more for myself, I just started a angular2 project and it's still not too late to change to something else. I do know google deprecates older versions quickly so I wouldn't consider angular1 anyway.

Google has very clearly stated that Angular 1.x will continue to receive full support and updates, as it is a completely separate product from Angular 2.

Edit: I think one of the telling signs is that the Angular.io website (the home of Angular 2) is written using Angular 1.6.0.

ModeSix fucked around with this message at 18:13 on Mar 11, 2017

Lumpy
Apr 26, 2002

La! La! La! Laaaa!



College Slice

Helicity posted:

I also just switched from using redux-thunk and redux-saga in work/personal projects to using middleware. Atomic units of work like resolving a fetch promise, or chain of network calls where I only care about the end result, are handled purely in middleware. Any other type of scheduling is handled by the React component's lifecycle. My action creators and reducers are stupid, simple, and synchronous now.

But Redux-thunk *is* middleware?

I get all of those nice things you describe while using it...

Professor of Cats
Mar 22, 2009

ModeSix posted:

Google has very clearly stated that Angular 1.x will continue to receive full support and updates, as it is a completely separate product from Angular 2.

Edit: I think one of the telling signs is that the Angular.io website (the home of Angular 2) is written using Angular 1.6.0.

Plus side of using Angular 1 right now; it has a TON of community support; use case examples, solved issues (meaning if you are trying to do X, odds are, someone already did it and pretty decently). I'm using both Angular 1 and 2 for a couple projects (not together obviously) for both web and mobile and I love them.

For those that are new to web dev in general, I would recommend going Angular 1.6.x over Angular 2 for reasons I stated above. Using all the available help/examples provided with an existing and fully vetted framework, you will be able to become confident with all of the existing web dev techniques and be confident enough to branch out learning the newer stuff. Also, it helps with learning all the asset pipeline stuff (grunt, gulp, bare bones NPM scripts, etc).

Hell, some of my company's "older" products that are still being used heavily are in Knockout.

As for "outdated" javascript frameworks; let's say you jump on Knockout or let's even say Angular 1 was just flat out dropped; it still works really well as it is right now and any bugs you come across you can shim in your own fixes if need be; (that isn't even counting the huge user base doesn't come up with its own fix first).

That is my humble opinion. :)

ToxicSlurpee
Nov 5, 2003

-=SEND HELP=-


Pillbug
If memory serves the Google policy is that Angular 1 quits getting updates when half of Angular use is Angular 2. Everything will eventually have its life ended but Angular 1 is already on the chopping block. That's the reason we decided not to use Angular 1 at work while neither of us were all that impressed with 2.

Now we use Backbone. I actually really like Backbone.

Plavski
Feb 1, 2006

I could be a revolutionary
Yo're not a JavsScript developer unless you're jumping on board the latest and greatest, no matter what the intellectual cost. That's why I'm a professional Aurelia developer :smugbert:

Skandranon
Sep 6, 2008
fucking stupid, dont listen to me

ModeSix posted:

I don't see how this question is really even a good question.

Angular 1 and Angular 2 are basically two almost completely different toolsets that accomplish more or less the same thing.

It's like asking someone why they're using React instead of Aurelia. Going from Angular 1 to 2 is not a straight upgrade path. Angular 2 is a completely different beast from 1.

Just my 2 cents worth on the topic.

If you are using Angular 1.5+, with TypeScript, and use components with their lifecycle hooks, it's actually quite similar to Angular 2, at least from a code structure perspective. I'm still not sold on Angular 2, still waiting to see how it plays out.

lunar detritus
May 6, 2009


We actually switched to Angular 2 (mostly because of Ionic 2) and Vue because of Angular 1's probable demise. Vue is quite nice though.

Kekekela
Oct 28, 2004
I feel like this js fatigue thing is seriously overblown, especially given how mature React et al are.

Kekekela fucked around with this message at 22:28 on Mar 11, 2017

Professor of Cats
Mar 22, 2009

gmq posted:

We actually switched to Angular 2 (mostly because of Ionic 2) and Vue because of Angular 1's probable demise. Vue is quite nice though.

I went with Angular 2 on a new project as well; but I would ask/debate what "demise" actually means. Updates may stop from the team, but the community and usage won't, IMHO. In fact; I'm using Angular 1.4 in another on going project and everything is just fine. The bugs I've ran into all have had non-official work arounds.

luchadornado
Oct 7, 2004

A boombox is not a toy!

Lumpy posted:

But Redux-thunk *is* middleware?

I get all of those nice things you describe while using it...

Kekekela posted:

Sorry for being dense but I don't think I'm following exactly what you're saying here. I thought redux-thunk was my middleware. :confused:

I should have said "writing custom middleware and keeping action creators fully synchronous" instead of "using middleware".

redux-think *is* middleware, and it essentially just allows you to write action creators that return functions. This sounds benign, but can easily lead to really horrible things with asynchronicity in your action creators. I'm talking about multiple dispatches and setTimeouts and Promises everywhere. Testing and troubleshooting these action creators are not fun. It's probably not as noticeable with smaller apps, but it becomes really apparent as your apps get larger and more complex.

Writing middleware to handle async units of work and letting component lifecycle drive the actions helps keeps things compartmentalized, easily testable, and feels much easier to reason about. All your action creators suddenly become very simple, and the event loop is no longer this alien entity. It's one of those things where Dan Abramov has said he regrets making redux-thunk and instead promotes writing middleware, people will say it can be better, but you might not ever truly see how/why it's better until you experience pain and then go through the exercise of rewriting.

Long story short: if you find it difficult to reason about your app's state management, unit testing becomes a nightmare, and/or you're getting scaling headaches give it a try. If thunks are working for you and you haven't spent time thinking about better ways of doing things while in the shower, don't worry about it.

an skeleton
Apr 23, 2012

scowls @ u
For the main app I'm working on right now, we're on Redux-saga after moving away from redux-loop for our async stuff and handling long transactional stuff (e.g. using redux-saga 'race' to handle complex menu interactions which can be a series of different actions). Pretty happy with it so far, except we haven't wrapped our head around unit testing the sagas yet, and I have a feeling that's going to be quite the task for some of the more complicated sagas. I *can* envision them being tough to debug, especially once you have multiple sagas running in the background.

Anyways, I was wondering -- how do y'all evaluate 3rd party front-end libs to use in your project? I'm in need of a react carousel and there's at least 3 options to consider. I find that, after desirable features, I'm always biased towards picking 3rd party packages that have the most "stars" or contributors listed on github; my thought is that kinks and errors are more likely to be fixed or known by the community, but I don't know that that's how it always translates into reality.

Kekekela
Oct 28, 2004

an skeleton posted:

picking 3rd party packages that have the most "stars" or contributors listed on github

Pretty much same but including how recently and frequently the project is updated.

prom candy
Dec 16, 2005

Only I may dance

Kekekela posted:

I feel like this js fatigue thing is seriously overblown, especially given how mature React et al are.

It's just bad developers who hate the idea of ever learning anything new.

Helicity posted:

I should have said "writing custom middleware and keeping action creators fully synchronous" instead of "using middleware".

redux-think *is* middleware, and it essentially just allows you to write action creators that return functions. This sounds benign, but can easily lead to really horrible things with asynchronicity in your action creators. I'm talking about multiple dispatches and setTimeouts and Promises everywhere. Testing and troubleshooting these action creators are not fun. It's probably not as noticeable with smaller apps, but it becomes really apparent as your apps get larger and more complex.

Writing middleware to handle async units of work and letting component lifecycle drive the actions helps keeps things compartmentalized, easily testable, and feels much easier to reason about. All your action creators suddenly become very simple, and the event loop is no longer this alien entity. It's one of those things where Dan Abramov has said he regrets making redux-thunk and instead promotes writing middleware, people will say it can be better, but you might not ever truly see how/why it's better until you experience pain and then go through the exercise of rewriting.

Long story short: if you find it difficult to reason about your app's state management, unit testing becomes a nightmare, and/or you're getting scaling headaches give it a try. If thunks are working for you and you haven't spent time thinking about better ways of doing things while in the shower, don't worry about it.

Can you post an example of this?

luchadornado
Oct 7, 2004

A boombox is not a toy!

prom candy posted:

It's just bad developers who hate the idea of ever learning anything new.

It's a lot of churn that is even more apparent when you have experience in a more stable ecosystem like Java, Python, or C# (even including Core CLR). One problem is the tendency towards modular architectures that make documenting the interaction between modules critical, but most authors consider that outside the scope of their concerns. The other problem is that documentation in general is poor for many of these projects, so blog posts and tweets are useful sources of information but become outdated very quickly. A React boilerplate from 2015 can be unusable in 2017, for example. Steps are being made, so there's hope - Redux and Webpack both got healthy updates to their documentation.

Dismissing frustration with the ecosystem as a fear of learning isn't fair. I'd rather solve interesting problems or play with Haskell/Kubernetes/whatever than figuring out yet another modular build tool for JS.

prom candy posted:

Can you post an example of this?

Code changed to protect the innocent: using redux-thunk, making your action creators brittle, difficult to reason about, and difficult to test. Every single async action creator you need has to be complex like this:

code:
export function loadStuff(queryParams) {
  return (dispatch) => {
    const eventsQuery = new StuffQuery(queryParams);
    const { minTs, maxTs } = queryParams;
    dispatch(setSelectedStartDate(minTs));
    dispatch(setSelectedEndDate(maxTs));
    dispatch({ type: LOADING });

    return Promise.resolve(StuffService.getStuff(eventsQuery))
      .then((resp) => {
        const Stuff = new StuffResponse(resp.data);
        const formattedStuff = StuffFormatter.formatStuff(Stuff);

        dispatch({
          type: STUFF,
          formattedStuff,
          eventsQuery,
        });
      })
      .catch((e) => {
        switch (e.message) {
          case FETCH_ERRORS[FETCH_ERRORS.TYPE_A]: {
            dispatch({ type: LOAD_EVENTS_TYPE_A_ERROR });
            break;
          }
          case FETCH_ERRORS[FETCH_ERRORS.NOT_AUTHORIZED]: {
            dispatch({ type: LOAD_EVENTS_NOT_AUTHORIZED_ERROR });
            break;
          }
          default: {
            dispatch({ type: LOAD_EVENTS_UNCLASSIFIED_ERROR });
            break;
          }
        }
      });
  };
};
With custom middleware, you write some middleware that does something like fetches from an API:

code:
// My action creator
export function loadStuff(payload) {
  return {
    type: FETCH_API_REQUEST,
    payload,
  }
};

// My middleware
const fetchAPIMiddleware = store => next => action => {
  if (!action.payload || !action.payload.url) { return next(action); }
  const { url, moduleName } = action.payload;

  fetch(url)
    .then((resp) => {
      if (!resp.ok) {
        next({ type: FETCH_FAILURE, moduleName, error: 'Error fetching' });
      } else {
        resp.json()
          .then((data) => {
            next({ type: FETCH_SUCCESS, moduleName, data });
          });
    });
}
You would write middleware called something like fetchAPI that looks for the existence of a payload property on the action. It would handle the actual fetch call and the promise resolution. On resolve, it could dispatch FETCH_API_SUCCESS, and rejection FETCH_API_FAILURE. Then just have your reducer look for those actions and update the state appropriately. In the component that cares about the results of this hypothetical call: if you want the API call on init, fire the action from componentDidMount. If you want it on demand from a control, pass it in as an onClick prop or however you like. If you want it to continuously poll: track a setTimeout reference in the component class, fire the action and start a new setTimeout when props updated indicating a previous call finished, clearTimeout on the reference in componentWillUnmount.

Pros:
- More modular, so easier to share across app
- Complex logic confined to a single place (middleware)
- Synchronization/scheduling is driven by the component that actually needs the data
- Easier to unit test all aspects: action creators are dead simple, generic async behavior tested once, rely on guarantees of React lifecycle

Cons:
- Requires more design thought up front, thunks are great for just getting it working right away
- Currying can be kind of confusing at first

I'd probably still recommend thunks for scenarios where you're not unit testing (hopefully just POCs/demos) or doing a very small handful (1-2) async actions throughout your entire app.

This is a great resource for starting, although be prepared to spend some time figuring out how currying/partial application/function composition work if that doesn't come naturally to you:
http://redux.js.org/docs/advanced/Middleware.html

luchadornado fucked around with this message at 16:28 on Mar 12, 2017

Kekekela
Oct 28, 2004
Thanks for posting that. Definitely gives me some ideas for inverting our current async paradigm. Its not that its super hard to reason about but there's way too much ceremonial code around handling every network success, failure and in progress event.

Also I know I'm really late to the party on this one but I just stumbled onto the magic of CSS3 Multi Column layouts while working on a side project this morning.

Adbot
ADBOT LOVES YOU

Thermopyle
Jul 1, 2003

...the stupid are cocksure while the intelligent are full of doubt. —Bertrand Russell

I do something similar on an app that's got around 30 different API calls and some dependent calls (like, "do X then Y unless X has already been done, then just Y"). It cleans stuff up.

You do have to be careful that you're not just moving complexity from a thunk to a middleware. No gain in doing that.

Also, another potential downside is that you're creating a spooky action at a distance. Like everything you have to think about the tradeoffs you're making.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply