Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »

prom candy: Dec 16, 2005; Only I may dance

Odette posted:

Well, you could always create a plugin that does just that.

There are many plugins, but you have to eject to use them! It looks like people have found some workarounds (including turning your SVGs into components) but Dan Abramov has also expressed interest in adding raw loading to a future version of CRA.

https://github.com/facebookincubator/create-react-app/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20raw

# ? Oct 26, 2017 14:11

Adbot: ADBOT LOVES YOU

# ? Jun 9, 2024 04:43

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

prom candy posted:

I wish CRA would allow raw file imports. Getting pretty sick of converting all my svgs to react components just to inline them.

But it does? Raw SVG file import and use is featured in the template project that create-react-app spits out:

JavaScript code:

import React, { Component } from 'react';
import logo from './logo.svg';
import './App.css';

class App extends Component {
  render() {
    return (
      <div className="App">
        <header className="App-header">
          <img src={logo} className="App-logo" alt="logo" />
          <h1 className="App-title">Welcome to React</h1>
        </header>
        <p className="App-intro">
          To get started, edit <code>src/App.js</code> and save to reload.
        </p>
      </div>
    );
  }
}

export default App;

# ? Oct 26, 2017 16:34

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

IAmKale posted:

But it does? Raw SVG file import and use is featured in the template project that create-react-app spits out:

JavaScript code:

import React, { Component } from 'react';
import logo from './logo.svg';
import './App.css';

class App extends Component {
  render() {
    return (
      <div className="App">
        <header className="App-header">
          <img src={logo} className="App-logo" alt="logo" />
          <h1 className="App-title">Welcome to React</h1>
        </header>
        <p className="App-intro">
          To get started, edit <code>src/App.js</code> and save to reload.
        </p>
      </div>
    );
  }
}

export default App;

I suspect they mean using an SVG directly as a react component instead of as an img source. Right now you have to open your SVG file and turn it into a component like;

code:

//myIcon.js
export default () => <svg> ... </svg>

//index.js
import MyIcon from �./myIcon�
<Button >  <MyIcon /> Super! </Button >

And it would be nice to just be able to do:

code:

import myIcon from �./myIcon.svg�
<Button > { myIcon } Super! </Button >

Lumpy fucked around with this message at 16:55 on Oct 26, 2017

# ? Oct 26, 2017 16:52

prom candy: Dec 16, 2005; Only I may dance

Yeah I'm talking about inline svg, which lets you modify it with CSS. If you import a .svg file in CRA you just get a computed path to it (which is obviously super handy for lots of other file types, or if you just want to use an svg as an img src.)

I make extensive use of inline svg because they're waaaaay better than icon fonts, but it's not THAT big of a deal to convert them to react components first.

# ? Oct 27, 2017 04:47

Love Stole the Day: Nov 4, 2012; Please give me free quality professional advice so I can be a baby about it and insult you

What's the recommended practice for querying the database for static info from the front-end? I have a project setup to refresh data every 5 minutes on the back-end. I'm thinking it'd just be simpler to keep the data stored by the server in a variable like a cache thing so the front-end would just query the stored data variable rather than query it directly every time someone makes a request to the server. That way, the database is only interacted with on the back-end, but I'm sure I'm doing something wrong.

For context, Here's a link to the app and here's a link to the Github

edit---- vvvvvvvvvvvvv Yeah sorry, I worded that badly. When I said querying from the front-end I meant to make a call to a back-end function that actually does the querying, like you said in your post. I did a bad job of explaining it.

Love Stole the Day fucked around with this message at 08:58 on Oct 27, 2017

# ? Oct 27, 2017 08:34

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

Love Stole the Day posted:

What's the recommended practice for querying the database for static info from the front-end? I have a project setup to refresh data every 5 minutes on the back-end. I'm thinking it'd just be simpler to keep the data stored by the server in a variable like a cache thing so the front-end would just query the stored data variable rather than query it directly every time someone makes a request to the server. That way, the database is only interacted with on the back-end, but I'm sure I'm doing something wrong.

For context, Here's a link to the project and here's a link to the Github

Under no circumstance should a public facing UI interface directly with a database, it should at least be going through a backend that fetches the data from the database. As to a caching mechanism, you should probably let the database handle that. It will cache frequently made requests, and it's likely a fairly sophisticated cache. Only write your own when you can demonstrate it has a real benefit.

# ? Oct 27, 2017 08:48

Capri Sun Tzu: Oct 24, 2017; by Reene

Love Stole the Day posted:

What's the recommended practice for querying the database for static info from the front-end? I have a project setup to refresh data every 5 minutes on the back-end. I'm thinking it'd just be simpler to keep the data stored by the server in a variable like a cache thing so the front-end would just query the stored data variable rather than query it directly every time someone makes a request to the server. That way, the database is only interacted with on the back-end, but I'm sure I'm doing something wrong.

For context, Here's a link to the app and here's a link to the Github

edit---- vvvvvvvvvvvvv Yeah sorry, I worded that badly. When I said querying from the front-end I meant to make a call to a back-end function that actually does the querying, like you said in your post. I did a bad job of explaining it.

Is it an option to use a database that supports push messaging, like Redis, Mongo, Firebase etc?

# ? Oct 27, 2017 14:48

Rubellavator: Aug 16, 2007

Love Stole the Day posted:

What's the recommended practice for querying the database for static info from the front-end? I have a project setup to refresh data every 5 minutes on the back-end. I'm thinking it'd just be simpler to keep the data stored by the server in a variable like a cache thing so the front-end would just query the stored data variable rather than query it directly every time someone makes a request to the server. That way, the database is only interacted with on the back-end, but I'm sure I'm doing something wrong.

For context, Here's a link to the app and here's a link to the Github

edit---- vvvvvvvvvvvvv Yeah sorry, I worded that badly. When I said querying from the front-end I meant to make a call to a back-end function that actually does the querying, like you said in your post. I did a bad job of explaining it.

I've done that before using guava's CacheLoader.

# ? Oct 27, 2017 14:55

smackfu: Jun 7, 2004

Upgrading from AngularJS to Angular is the most perfect example of pure technical debt. There�s basically no real benefit, it�s an awful lot of work, but we feel like we need to do it so we don�t fall behind.

# ? Oct 27, 2017 23:29

Blue Max: May 1, 2003; Yeah I know this Pi shit backwards and forwards.

smackfu posted:

Upgrading from AngularJS to Angular is the most perfect example of pure technical debt. There�s basically no real benefit, it�s an awful lot of work, but we feel like we need to do it so we don�t fall behind.

I'm in exactly the same boat but to be fair, I'm looking forward to getting a Webpack based build and using Typescript. It's just finding a spare week or four to port the application over. Wonder if ng-upgrade will do anything for us?

# ? Oct 31, 2017 22:39

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

smackfu posted:

Upgrading from AngularJS to Angular is the most perfect example of pure technical debt. There�s basically no real benefit, it�s an awful lot of work, but we feel like we need to do it so we don�t fall behind.

Considering most dev jobs are happy enough to accept that you have Angular 1.X under your belt you should be fine.

Plus its not like Google isn't making GBS threads out versions every 5 minutes now. 5.0 was released, like, yesterday?

# ? Nov 2, 2017 11:55

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

I'm working on a directive in Angular 1.5 that hits a weather API for some information, but we (potentially) pay per hit to the API, so I'd like to avoid it if the element the directive renders to isn't visible. What's the least bad way to wait for the element to be visible before hitting the API?

My current thought it putting a watch on the scroll position and when it gets within ~10px of the computed top of the element, letting the API call happen and removing the watch, which I have a fairly fuzzy idea of how to do most of.

# ? Nov 2, 2017 15:20

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

Munkeymon posted:

I'm working on a directive in Angular 1.5 that hits a weather API for some information, but we (potentially) pay per hit to the API, so I'd like to avoid it if the element the directive renders to isn't visible. What's the least bad way to wait for the element to be visible before hitting the API?

My current thought it putting a watch on the scroll position and when it gets within ~10px of the computed top of the element, letting the API call happen and removing the watch, which I have a fairly fuzzy idea of how to do most of.

Eugh... no. You shouldn't have any UI components/directives making network calls, you should put that in a service. This will also let you do your own caching.

You could then build a component/directive that monitors your scroll window and makes the appropriate service call when you want to show it. No need for a watch, you can attach handlers to the scroll event, just make sure you manually digest your component when you get your data back from the service call.

# ? Nov 2, 2017 16:49

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Is using a directive's link function to tack the DOM element to the scope the least bad way to get it to the controller?

JavaScript code:

function SomeDirective() {
  return {
    controller: SomeDirectiveController,
    bindToController: true,
    link: function (scope, ele, whocares) {
      scope.element = ele;
    }
  };
}

function SomeDirectiveController () {
  this.$onInit = function () {
    requestAnimationFrame(function () {
      //now I can actually count on element being there
    }
  };
}

Seems a bit much?

# ? Nov 2, 2017 17:20

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Skandranon posted:

Eugh... no. You shouldn't have any UI components/directives making network calls, you should put that in a service. This will also let you do your own caching.

You could then build a component/directive that monitors your scroll window and makes the appropriate service call when you want to show it. No need for a watch, you can attach handlers to the scroll event, just make sure you manually digest your component when you get your data back from the service call.

Yeah, it's using a comms service, I was glossing over all of that. Turns out watching $window.scrollY doesn't work anyway, so I'm doing $document.on('scroll', scrollHandler);.

What do you mean by manually digest?

# ? Nov 2, 2017 17:24

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Oh, maybe I should move questions about Angular 1.5 out of the Modern thread, heh

# ? Nov 3, 2017 15:07

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

I'm going to be teaching someone about React+Redux and this is what I was thinking about in the shower this morning.

Here's the organizing principle of a React+Redux application:

The state, this big honkin object full of values, describes your UI.

You change some value in the state, your UI changes to reflect that. If you want a user click to change your UI, you don't figure out how to move a dom node, you change the state and your state flows into your UI.

You should be able to serialize your whole state tree, and when the user comes back, deserialize the state tree, and the UI will be exactly as it was when they left. (great feature of React+Redux)

Your whole application is described by a series of actions that change the state and the state itself.

Sometimes, there's minor-ish UI transitions or updates that its just easier to not have linked to your application state. A good way to decide if this is the case is to think about the case where you serialize your state and the user leaves and comes back later...is it even theoretically useful for this UI thingy to be saved? Even if you're not implementing state serialization/deserialization, use it as a way to enforce a line where the UI should be in the state or not.

# ? Nov 3, 2017 16:03

prom candy: Dec 16, 2005; Only I may dance

That's a great way of putting it I think. I might give an example of the kinds of things you would use local component state for. Two examples I give a lot are uncommitted changes to form fields, and confirmation dialogs. When I'm showing it to new users I like to get them in the Redux DevTools window as early as possible so that they can see what happened, how it changed the state, and what the whole state tree looks like.

# ? Nov 3, 2017 17:45

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

Munkeymon posted:

What do you mean by manually digest?

Probably should have elaborated a bit on that one, left some things out, but now that you've asked...

I don't like the $http service in Angular, as it does some sneaky things to make magic happen. Basically, $http has a reference to $rootScope, and attaches a .then(() => $rootScope.$digest()) to all your HTTP requests made through it. This is useful when doing a tiny app that clicks button, loads data, data appears. It appears not because of the implicit $scope.apply attached by the ng-click directive, but by the $rootScope.$digest() from $http. This is bad for two reasons. One, it is bad for performance, as this is a digest on the entire application, even if the data you loaded was just a boolean to change a single icon. Two, it completely breaks any separation of concerns, as your backend-only data layer is now implicitly plugged into the draw cycle of everything. It means you will be implicitly digesting whenever you call things that don't even affect the state of your application.

To fix this, and to be more modern, you should use window.fetch() to make your HTTP calls. Cleaner API, and uses ES6 promises. However, when you DO load data that you want to display, you'll need to add your own .then(() => this.scope.$digest()) to your requests (ideally in the controller that made them). This will properly push the responsibility to digest to your controllers, where it should be, and because it is there, you can digest only on the scope that is changing.

# ? Nov 4, 2017 03:12

lunar detritus: May 6, 2009

While using redux (or vuex, ngrx, or anything with that pattern), is there a pattern for reconstructing objects from what's in the state and adding methods to them? A (bad) example would be

JavaScript code:

event.isToday()
//vs
isEventToday(event.date)

The latter is ok if I need that computed data in only one place, but what if I need it in multiple places/components? Should I always precompute that kind of thing in the store when getting it?

# ? Nov 4, 2017 16:21

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

gmq posted:

While using redux (or vuex, ngrx, or anything with that pattern), is there a pattern for reconstructing objects from what's in the state and adding methods to them? A (bad) example would be
JavaScript code:
event.isToday()
//vs
isEventToday(event.date)
The latter is ok if I need that computed data in only one place, but what if I need it in multiple places/components? Should I always precompute that kind of thing in the store when getting it?

For computed data that will be accessed more than once (either in many views, or the workflow of the app meaning people come back to the same view many times) you can use selectors to cache the computed result.

There are libraries like reselect that provide an easy way to do this. So if the state is the same as the last time you asked for the result, you get a cached lookup. Different state, it will recompute. You can compose selectors so you can be as efficient as possible. Phone posting so I am too lazy to make an example. The reselect Readme has a bunch though!

# ? Nov 4, 2017 16:56

prom candy: Dec 16, 2005; Only I may dance

So if you use reselect for these kinds of helpers/derived data methods then you just link them up in your mapStateToProps function? I've been putting stuff like isEventToday() in standalone helper files, never really thought to use selectors for stuff like that.

# ? Nov 4, 2017 18:00

Dogcow: Jun 21, 2005

prom candy posted:

So if you use reselect for these kinds of helpers/derived data methods then you just link them up in your mapStateToProps function? I've been putting stuff like isEventToday() in standalone helper files, never really thought to use selectors for stuff like that.

Yup, so on state change the memorized selectors can evaluate their inputs from the state and decide whether to use the cached value or not. Centralized selectors are also good since if you access the same part of state in multiple places (or multiple composed selectors) and your state shape changes you have a single place to update that.

# ? Nov 4, 2017 19:13

darthbob88: Oct 13, 2011; YOSPOS

Working on my first React/Redux app, and is there a good way to handle moderately-complicated form input other than the complication of Redux-Form? I'm trying to specifically recreate this component in React. At present, the best method I can really think of is to create an onSubmit function in mapDispatchToProps that just takes all those fields to build a new Task, and I can't help thinking that there's a better way.

# ? Nov 4, 2017 21:59

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Try to resist using redux form. It�s an inappropriate toy in small apps and a clear performance problem on big ones because it means every keystroke will go through the entire redux reduction codepath, which means every keystroke is almost guaranteed to chug on mobile.

Honestly I feel no problems just using local React state to handle forms, and then an action creator to handle submission of the form data once you�ve gotten past any validate as you type work or whatever.

Nested in-line forms like the component you sort of showed are probably better for avoiding redux too, provided your interactive code calls back appropriately to redux when the application state needs to commit user action.

The benefit of keeping it React local state, is you can probably isolate the state for subforms safely without having to deal with how to place and key it in the redux state.

I�m sure there�ll be some disagreement on what I�ve said here, but my experience in trying to use redux-UI and redux-forms has borne out to me not liking redux for storing form data as it�s typed, and an unnecessary complication of the problem compared to using React�s local state. Mileage may vary and all.

# ? Nov 4, 2017 22:16

darthbob88: Oct 13, 2011; YOSPOS

Maluco Marinero posted:

Try to resist using redux form. It�s an inappropriate toy in small apps and a clear performance problem on big ones because it means every keystroke will go through the entire redux reduction codepath, which means every keystroke is almost guaranteed to chug on mobile.

Honestly I feel no problems just using local React state to handle forms, and then an action creator to handle submission of the form data once you�ve gotten past any validate as you type work or whatever.

Nested in-line forms like the component you sort of showed are probably better for avoiding redux too, provided your interactive code calls back appropriately to redux when the application state needs to commit user action.

The benefit of keeping it React local state, is you can probably isolate the state for subforms safely without having to deal with how to place and key it in the redux state.

I�m sure there�ll be some disagreement on what I�ve said here, but my experience in trying to use redux-UI and redux-forms has borne out to me not liking redux for storing form data as it�s typed, and an unnecessary complication of the problem compared to using React�s local state. Mileage may vary and all.

What, so I just have an internal newTask object that I build from the inputs, and then the Save button gets an onClick(dispatch({type: "NEW_TASK", newTask: this.newTask}))? That's kinda what I'd like to do, but how the hell do I actually make that happen? Do I need to do it with a class component like this? Because I was feeling really clever for doing everything in functional components.

# ? Nov 4, 2017 23:00

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

darthbob88 posted:

What, so I just have an internal newTask object that I build from the inputs, and then the Save button gets an onClick(dispatch({type: "NEW_TASK", newTask: this.newTask}))? That's kinda what I'd like to do, but how the hell do I actually make that happen? Do I need to do it with a class component like this? Because I was feeling really clever for doing everything in functional components.

There's nothing wrong with class-based components. I simply keep every input value in local state (populated by an `initialFormState` prop object if I'm editing) and then consolidate them into an object or whatever on submit / "go" button click / whatever event(s) should cause something to happen. I have some generic validators that I compose for each field (plus any specific ones) that run through a generic validate function so I can validate on submit, and on user input as needed.

But yeah, forms are the perfect use case for class-based components.

# ? Nov 5, 2017 01:37

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Also, class based components are NECESSARY if you�re gonna make truly rich interactive self contained components. Eventually the redux model just ends up way too heavy handed for particular types of interaction you need in a rich web app.

Functional components should be a default but not a dogma, as it does you no favours to stick to it when trying to put widget actions in redux, the state ends up miles away from the functionality and not in a nice decoupled way, it�s just needless misdirection.

# ? Nov 5, 2017 01:55

Pollyanna: Mar 5, 2005; Milk's on them.

At this point we're just re-litigating the age-old "how do you design your UI state" debate. Sometimes you need components that have their own local state, sometimes it's more efficient to use a functional component instead of one with local state. :shrug:

# ? Nov 5, 2017 03:49

darthbob88: Oct 13, 2011; YOSPOS

Lumpy posted:

There's nothing wrong with class-based components. I simply keep every input value in local state (populated by an `initialFormState` prop object if I'm editing) and then consolidate them into an object or whatever on submit / "go" button click / whatever event(s) should cause something to happen. I have some generic validators that I compose for each field (plus any specific ones) that run through a generic validate function so I can validate on submit, and on user input as needed.

But yeah, forms are the perfect use case for class-based components.

Yeah, that sounds like exactly what I want to do, but there's another wrinkle. I'm also trying to do this in Typescript, because Typescript is excellent, and apparently class components in Typescript have issues, according to luca-moser's example. Even this simple example refuses to compile, because it can't find setState or props on the StatefulCounter component. I'm beginning to think it might just be easier to cram all the parameters I need into the onSubmit call. It's terrible, but I can make it work immediately.

# ? Nov 5, 2017 06:20

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

darthbob88 posted:

Yeah, that sounds like exactly what I want to do, but there's another wrinkle. I'm also trying to do this in Typescript, because Typescript is excellent, and apparently class components in Typescript have issues, according to luca-moser's example. Even this simple example refuses to compile, because it can't find setState or props on the StatefulCounter component. I'm beginning to think it might just be easier to cram all the parameters I need into the onSubmit call. It's terrible, but I can make it work immediately.

Once again being too lazy to learn typsescript pays off. :smug:

Now if you'll excuse me, I need to go track down this wired error I'm getting....

# ? Nov 5, 2017 07:07

prom candy: Dec 16, 2005; Only I may dance

I'm using Typescript with class components and they Just Work. Did you install the typings from DefinitelyTyped?

# ? Nov 5, 2017 07:13

M31: Jun 12, 2012

You can try Formik as well. It just provides some local state and some helper methods for validation. You still do all the rendering yourself, which is a large improvement over other libraries. It also comes with Typescript definitions.

# ? Nov 5, 2017 07:46

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Every time I use a form library I feel like I end up doing just as much work as if I hadn't.

# ? Nov 5, 2017 15:48

darthbob88: Oct 13, 2011; YOSPOS

prom candy posted:

I'm using Typescript with class components and they Just Work. Did you install the typings from DefinitelyTyped?

I had not, I thought I'd read somewhere that Typescript could automatically install those. Just added them to packages.json and now the class component works fine. Woo, back to work.

# ? Nov 5, 2017 16:20

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

darthbob88 posted:

I had not, I thought I'd read somewhere that Typescript could automatically install those. Just added them to packages.json and now the class component works fine. Woo, back to work.

TypeScript does install it's own lib.d.ts to describe some basic JavaScript objects, like window and console, but doesn't magically know what frameworks you are using. Many packages now can include d.ts files, and TypeScript can now use the @types npm namespace, but that doesn't happen automatically.

# ? Nov 5, 2017 17:40

prom candy: Dec 16, 2005; Only I may dance

There's a setting that will refuse to compile if it can't find typings for your imports, which means you'll be reminded to install the typings after installing a third-party library, or manually add a declaration for it (literally just one line basically saying "yeah I know I don't have typings for this and I'm okay with that.") I'm not sure which setting it is though... maybe noImplicitAny? My first foray into Typescript has been with a create-react-app so a lot of it was preconfigured for me. Here's my whole tsconfig.json:

code:

{
  "compilerOptions": {
    "allowSyntheticDefaultImports": true,
    "outDir": "build/dist",
    "module": "esnext",
    "target": "es5",
    "lib": ["es6", "dom"],
    "sourceMap": true,
    "allowJs": true,
    "jsx": "react",
    "moduleResolution": "node",
    "rootDir": "src",
    "baseUrl": "./src",
    "forceConsistentCasingInFileNames": true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "suppressImplicitAnyIndexErrors": true,
    "noUnusedLocals": true
  },
  "exclude": [
    "node_modules",
    "build",
    "scripts",
    "acceptance-tests",
    "webpack",
    "jest",
    "src/setupTests.ts"
  ]
}

# ? Nov 5, 2017 17:57

Newf: Feb 14, 2006; I appreciate hacky sack on a much deeper level than you.

Skandranon posted:

TypeScript does install it's own lib.d.ts to describe some basic JavaScript objects, like window and console, but doesn't magically know what frameworks you are using. Many packages now can include d.ts files, and TypeScript can now use the @types npm namespace, but that doesn't happen automatically.

There is some set of conditions where this does happen automatically, at least in VSCode.

It does something to the effect of reading your package.json file, checking if type definitions are available inside the installed packages, and then checking for and automatically pulling down /packages/@types/packageX. It's magical (ie, tricky as hell) in so far as it doesn't add these types to your package.json or otherwise let you know that it's done anything behind the scenes to make things work, but instead it caches a local copy of the definitions for its intellisense and for the typescript compiler. I think it only works out if you're using a VSCode configured build task, and everything blows up (fails to compile) when you try to compile the same project from the command line.

I dunno. Too much abstraction, too many hidden moves?

# ? Nov 5, 2017 19:15

HaB: Jan 5, 2001; What are the odds?

Ugh.

In today's episode of "Super Poorly Documented Javascript Frameworks":

ag-grid

Has anyone used it? And more specifically, has anyone found an Angular example somewhere of A - loading data into it asynchronously AND B - using a Component as a CellRenderer?

I keep saying you can fix the async problem by listening for an event called gridReady, but for the life of me either I am listening entirely wrong, or it's simply not firing.

I have this:

Markup:

code:

<ag-grid-angular #grid 
                [gridOptions]="gridOptions"
                [columnDefs]="columnDefs"
                (gridReady)="onGridReady($event)"
 
...

and typescript:

code:

onGridReady(event) {
        console.log('grid ready...');
        this.loadAll();
}

That log statement never fires. Tried with $event and without. The documentation is awful, and after posting in an issue thread on github, the advice was "are you using the CLI? Because you should use the CLI" . Great, except this is a work project and was generated with JHipster, and I have no choice.

Also: the grid works fine if I just use a plain <div> in the markup, create a Grid object in typescript and bind it. Problem is - if you do it that way, it won't let you use a Component as a CellRenderer.

Ugh. Is it Friday yet?

# ? Nov 6, 2017 15:14

Adbot: ADBOT LOVES YOU

# ? Jun 9, 2024 04:43

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Skandranon posted:

Probably should have elaborated a bit on that one, left some things out, but now that you've asked...

I don't like the $http service in Angular, as it does some sneaky things to make magic happen. Basically, $http has a reference to $rootScope, and attaches a .then(() => $rootScope.$digest()) to all your HTTP requests made through it. This is useful when doing a tiny app that clicks button, loads data, data appears. It appears not because of the implicit $scope.apply attached by the ng-click directive, but by the $rootScope.$digest() from $http. This is bad for two reasons. One, it is bad for performance, as this is a digest on the entire application, even if the data you loaded was just a boolean to change a single icon. Two, it completely breaks any separation of concerns, as your backend-only data layer is now implicitly plugged into the draw cycle of everything. It means you will be implicitly digesting whenever you call things that don't even affect the state of your application.

To fix this, and to be more modern, you should use window.fetch() to make your HTTP calls. Cleaner API, and uses ES6 promises. However, when you DO load data that you want to display, you'll need to add your own .then(() => this.scope.$digest()) to your requests (ideally in the controller that made them). This will properly push the responsibility to digest to your controllers, where it should be, and because it is there, you can digest only on the scope that is changing.

Well that's interesting. I'll bring this up with the other guys who touch front-end stuff.

Also, surely you mean $window :whatup:

Uh, right? :ohdear:

E: oh hey what about my other question about getting an element reference into a directive's controller?

Munkeymon fucked around with this message at 16:47 on Nov 6, 2017

# ? Nov 6, 2017 16:26

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »