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

«‹›234 »

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Is there a way to minify Handlebars templates? I noticed that after building my ember-cli project, there is still a lot of redundant white space in the templates, poo poo like "<div><span class=\"butt\">cheeks</span>\r\n <span class=\"fart\">poot</span></div>". Those linefeeds, carriage returns and spaces don't need to be there.

It's not like it's a huge deal, but I'm wondering if it's possible in the first place.

# ? Nov 11, 2014 18:16

Adbot: ADBOT LOVES YOU

# ? Apr 28, 2024 14:41

Okita: Aug 31, 2004; King of toilets.

Looks like handlebars-precompiler would do the trick.

# ? Nov 11, 2014 21:01

Sedro: Dec 31, 2008

If you drill down in the dependencies, ember-cli uses the official handlebars precompiler. It probably doesn't minify the HTML (there is a minify option which I think refers to the JS output).

If you're using gzip compression (which you should) I wouldn't expect to see much savings anyway.

# ? Nov 11, 2014 21:49

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

I have a question about React, Backbone, and creating reusable modules for use with NPM, Gulp, and Browserify.

I'm making a webapp that uses React for its views, and I'm also planning to use Backbone to keep track of models and collections. Right now, I have everything in one bigass app/jsx/ folder where all my scripts live. I'm wondering how I would make an NPM module out of my React views, and my Backbone setup.

Right now, I'm importing my top-level React app like this:

code:

var MyApp = require('./app.jsx');

when I want to do something a little nicer, like this:

code:

var MyApp = require('my-app');

How would I package up a folder structure that looks something like this, so I can reuse it if I decide to redo my project?

├── app.jsx
├── authScreen
│�� ├── common
│�� │�� ├── authButton.jsx
│�� │�� ├── emailInput.jsx
│�� │�� ├── passwordConfirmation.jsx
│�� │�� └── passwordInput.jsx
│�� ├── loginScreen.jsx
│�� └── signupScreen.jsx
├── main.jsx
├── searchForm
│�� ├── cuisineSelection.jsx
│�� ├── locationInput.jsx
│�� ├── searchButton.jsx
│�� └── searchForm.jsx
├── searchResults
│�� ├── cuisineChoice.jsx
│�� ├── restaurantListing
│�� │�� ├── restaurantCard
│�� │�� │�� ├── cardInformation.jsx
│�� │�� │�� ├── profileImage.jsx
│�� │�� │�� └── restaurantCard.jsx
│�� │�� └── restaurantListing.jsx
│�� └── searchResults.jsx
└── title.jsx

# ? Dec 5, 2014 15:54

SuicideSnowman: Jul 26, 2003

In your package.json file you can add something like this:

code:

"browser": {
  "my-app": "./my-app/app.jsx",
}

That would allow you to require "my-app". As far as a cleaner folder structure, browserify also allows you to use an index.js file to organize things.

For example in your authScreen folder, you could put an index.js file that looks like this:

code:

require("./loginScreen.jsx");
require("./signupScreen.jsx");
require("./common/authButton.jsx");

Then simply calling a require("./authScreen") will cause browserify to look in the authScreen folder for your index.js file and process it. I'm not sure how React and Backbone work so there may be some additional steps required, but that's similar to how I do things with a fairly large AngularJS app.

SuicideSnowman fucked around with this message at 18:45 on Dec 5, 2014

# ? Dec 5, 2014 18:41

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

Aha, that's done it. Thanks :3:

I've figured out something with React: if you want to do make an AJAX-driven webapp type thing, don't pass in mutable data as properties - meaning, don't pass in a big ol' god object with a "user" and "meals" and "results" attributes. Instead, pass in only what you know will never change - in this case, the API URLs! Build all the data objects from JSON within getInitialState and componentDidMount, since those data objects will change over time.

Pollyanna fucked around with this message at 16:13 on Dec 8, 2014

# ? Dec 8, 2014 16:07

NovemberMike: Dec 28, 2008

Pollyanna posted:

Aha, that's done it. Thanks

I've figured out something with React: if you want to do make an AJAX-driven webapp type thing, don't pass in mutable data as properties - meaning, don't pass in a big ol' god object with a "user" and "meals" and "results" attributes. Instead, pass in only what you know will never change - in this case, the API URLs! Build all the data objects from JSON within getInitialState and componentDidMount, since those data objects will change over time.

I don't necessarily have anything against this but as far as I know this isn't really the recommended way of looking at it. Have you looked at Flux at all?

# ? Dec 8, 2014 23:21

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

I'm still wrapping my head around Flux. The Dispatcher pattern is a very new concept to me and the way data stores work requires an adjustment when coming from the Models of MVC. As for it not being recommended, it may be that way - this is just what works best for (and makes the most sense to) me.

There's another thing about React that I'm thinking about. I currently have a form declared something like this (WIP):

code:

var CommentForm = React.createClass({
  getInitialState: function() {
    return {
      title: '',
      text: ''
    };
  },
  render: function() {
    return (
      <form class='comment-form'>
        <CommentTitleInput />
        <CommentTextInput />
        <CommentSubmitButton />
      </form>
    );
  }
});

var CommentTitleInput = Render.createClass({
  getInitialState: function() {
    return {
      title: ''
    };
  },
  render: function() {
    return (
      <div class='comment-title-input'>
        <label>Comment Title</label>
        <input placeholder="My Title"></input>
      </div>
    );
  }
});

var CommentTextInput = Render.createClass({
  getInitialState: function() {
    return {
      text: ''
    };
  },
  render: function() {
    return (
      <div class='comment-text-input'>
        <label>Comment Text</label>
        <input placeholder="My Text"></input>
      </div>
    );
  }
});

var CommentSubmitButton = Render.createClass({
  render: function() {
    return (
      <button>Add Comment</button>
    );
  }
});

Currently, the CommentForm holds a title state and a text state. The CommentTitleInput also holds a title state, and the CommentTextInput also holds a text state. I have a feeling this is incorrect - this seems to go against the "single source of truth" principle that the React docs talk about a lot.

Intuitively, I'd say that the CommentTitleInput keeps the title state and the CommentTextInput keeps the text state - but then it becomes difficult to actually submit the form, because neither of CommentForm's child components naturally have access to all the data that must be submitted. Meaning, I'd have to somehow make a function in CommentSubmitButton that "grabs" the data from CommentTitleInput and CommentTextInput and then posts the data to the server. Not only is that apparently discouraged in the React documents, I can't actually fuckin' do that, at least not in a way that isn't a huge pain in the rear end.

So the real solution is to keep the title and text state in the CommentForm component, and also create an onFormSubmit method to pass into CommentSubmitButton that will be called when the button is clicked and will submit the form - and also have access to the form's state, which holds the data that must be submitted!

It helps to think of it as an electronic appliance. The CommentForm has three wires going out to three outer pieces of electronics - one goes to the "input title" keyboard, another goes to the "input text" keyboard, and another goes to the "submit form" pushbutton. When using it, you type on the keyboards and then press the button. What's actually happening is that the outer components themselves don't do poo poo - they're just IO outlets that send data to the CommentForm black box.

What I'm wondering is how I'm supposed to "predict" where all this state should live. Why does the CommentForm keep the state, as opposed to its parent component(s)? Why shouldn't I just keep a global state in the topmost component that looks something like this?

code:

getInitialState: function() {
  return {
    blogPost: {
      article: {
        title: '',
        text: ''
      },
      commentsBox: {
        comments: [
          {
            title: '',
            text: ''
          }
        ],
        commentForm: {
          title: '',
          text: ''
        }
      }
    }
  };
}

You'd just pass in each bit of state to the matching components - e.g. blogPost.article to Article, blogPost.commentsBox to CommentsBox (parent of CommentForm), etc. I can't think of a reason NOT to do this, aside from there being a lot of passing around happening - but I feel that's a minor price to pay for ensuring a single source of truth for all state.

I know I'm kind of thinking of this in an odd way kinda, I've been trying to tackle a complicated SPA using React (how the gently caress do I dynamically change which component is rendered/currently exists

) and I've ran into enough pitfalls and confusion that I'm going back to the basics again. But I think I have a better handle on it now than I used to.

# ? Dec 9, 2014 16:50

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

Pollyanna posted:

Aha, that's done it. Thanks

I've figured out something with React: if you want to do make an AJAX-driven webapp type thing, don't pass in mutable data as properties - meaning, don't pass in a big ol' god object with a "user" and "meals" and "results" attributes. Instead, pass in only what you know will never change - in this case, the API URLs! Build all the data objects from JSON within getInitialState and componentDidMount, since those data objects will change over time.

One of the problems with this is that you have to think about your props too much and you end up with this massive house of cards where you've got to make sure you're passing just the right prop to just the right component.

Really, spend a week getting used to Flux. It will solve your problems.

# ? Dec 9, 2014 16:54

NovemberMike: Dec 28, 2008

Thermopyle posted:

One of the problems with this is that you have to think about your props too much and you end up with this massive house of cards where you've got to make sure you're passing just the right prop to just the right component.

Really, spend a week getting used to Flux. It will solve your problems.

To be fair, IIRC that's what Flux recommends. You use the top level view as a View-Controller, which passes data from the stores to the views through the props. The nice thing about this is that you can just print out the state of the view-controller at any point and get the entire state of the app.

# ? Dec 9, 2014 22:40

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

One problem that Flux has is that it exposes too much of the internal wiring, it feels like. Being expected to build an EventEmitter for every Store I make feels like busy work and like something that could be automagically abstracted away for me. I've got a reading list of React stuff to go through, so I'll try and see if there's a better explanation of it somewhere.

# ? Dec 9, 2014 22:42

abraham linksys: Sep 6, 2010

Pollyanna posted:

One problem that Flux has is that it exposes too much of the internal wiring, it feels like. Being expected to build an EventEmitter for every Store I make feels like busy work and like something that could be automagically abstracted away for me. I've got a reading list of React stuff to go through, so I'll try and see if there's a better explanation of it somewhere.

You can use one of the other Flux implementations around that hide some of the boilerplate; I've been using Fluxxor and it works well enough.

It makes it a little easier to reason about getting data from Flux - it has a FluxMixin that lets any component get any store, as long as either (a) it gets passed a Flux instance as a property or (b) it has a parent with FluxMixin that was passed the Flux instance. This means you can have a complex tree of components, all mixing in FluxMixin, and as long as the top-level component was passed Flux, all of the children can access it. That way, instead of managing a wildly complex props tree, you can do something like:

code:

render: function() {
  var currentContact = this.getFlux().getStore('ContractStore').currentContact;
  return <span>{currentContact.name}</span>
}

It also has a mixin that handles binding to changes in your store, which takes away a boilerplate. Plus, since Fluxxor still just uses an EventEmitter for its stores, you can add custom events when simply emitting that state changed isn't enough (which, in my experience, is a pretty serious issue with Flux).

# ? Dec 9, 2014 22:54

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

NovemberMike posted:

To be fair, IIRC that's what Flux recommends. You use the top level view as a View-Controller, which passes data from the stores to the views through the props. The nice thing about this is that you can just print out the state of the view-controller at any point and get the entire state of the app.

Flux only recommends that for sufficiently simple hierarchies. They recommend inserting view controllers further down your hierarchy when the complexity becomes high enough.

# ? Dec 9, 2014 23:24

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

Pollyanna posted:

One problem that Flux has is that it exposes too much of the internal wiring, it feels like. Being expected to build an EventEmitter for every Store I make feels like busy work and like something that could be automagically abstracted away for me.

This is mostly an illusion.

You create a store base class with your common functionality like addChangeListener, removeChangeListener, emitChange, etc, then you just extend that for each of your stores.

something like

JavaScript code:

var assign = require('object-assign');
var EventEmitter = require('events').EventEmitter;

var StoreBase = assign({, EventEmitter.prototype, {
  addChangeListener: function(callback) {
    this.on(CHANGE_EVENT, callback);
  },
  
  removeChangeListener: function(callback) {
    this.removeListener(CHANGE_EVENT, callback);
  },

  emitChange: function() {
    this.emit(CHANGE_EVENT);
  },
});

You write that code in one place and then you never write it again.

Then when you want to create a store, you

JavaScript code:

var StoreBase = require('./StoreBase');

var MessageStore = assign({}, StoreBase, {
  maekBusinessWork: function(seriousBusiness) {
    // I do serious business
  }
});

The code you add to each of your stores is logic that you've got to do anyway because it's your business logic.

I mean, there's a hurdle to implementing Flux because it works differently from most other patterns so it's hard to wrap your head around. Once you've got it where you really get it, it should seem super easy.

# ? Dec 9, 2014 23:40

NovemberMike: Dec 28, 2008

Thermopyle posted:

Flux only recommends that for sufficiently simple hierarchies. They recommend inserting view controllers further down your hierarchy when the complexity becomes high enough.

The impression I got was that the default was a single view-controller, and you should only use multiple view-controllers if your app is sufficiently complex. If at all possible you want to keep to a single view-controller.

I'm not sure how much stock I put in that right now, but that's the recommendation that I saw.

# ? Dec 10, 2014 03:48

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

NovemberMike posted:

The impression I got was that the default was a single view-controller, and you should only use multiple view-controllers if your app is sufficiently complex. If at all possible you want to keep to a single view-controller.

I'm not sure how much stock I put in that right now, but that's the recommendation that I saw.

That's literally what I just said.

# ? Dec 10, 2014 05:02

NovemberMike: Dec 28, 2008

Thermopyle posted:

That's literally what I just said.

There's a semantic difference. AFAIK the Flux docs don't really "recommend" adding additional view-controllers further down your hierarchy, they consider it more of a necessary evil for hugely complex stuff. The example Pollyanna gave had 3 elements: Blogpost, CommentsBox and CommentForm. At that point, my understanding is that you should still be using a single view-controller, and really you should still be using a single view controller for systems that are quite a bit more complex than that. I'm not sure how I feel about it in practice but one of the goals of Flux is to have a single point of entry for data in the views and you lose that once you move to multiple view-controllers.

# ? Dec 10, 2014 16:09

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

NovemberMike posted:

There's a semantic difference. AFAIK the Flux docs don't really "recommend" adding additional view-controllers further down your hierarchy, they consider it more of a necessary evil for hugely complex stuff. The example Pollyanna gave had 3 elements: Blogpost, CommentsBox and CommentForm. At that point, my understanding is that you should still be using a single view-controller, and really you should still be using a single view controller for systems that are quite a bit more complex than that. I'm not sure how I feel about it in practice but one of the goals of Flux is to have a single point of entry for data in the views and you lose that once you move to multiple view-controllers.

From here:

quote:

Occasionally we may need to add additional controller-views deeper in the hierarchy to keep components simple. This might help us to better encapsulate a section of the hierarchy related to a specific data domain. Be aware, however, that controller-views deeper in the hierarchy can violate the singular flow of data by introducing a new, potentially conflicting entry point for the data flow. In making the decision of whether to add a deep controller-view, balance the gain of simpler components against the complexity of multiple data updates flowing into the hierarchy at different points.

I'm not sure where (or if) we're disagreeing here.

Thermopyle fucked around with this message at 19:40 on Dec 10, 2014

# ? Dec 10, 2014 18:01

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

Maybe there's a singular top-level controller that splits off into smaller component controllers. Or something. Then technically there's a single source of data, it's just divided up.

# ? Dec 10, 2014 19:33

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

Pollyanna posted:

Maybe there's a singular top-level controller that splits off into smaller component controllers. Or something. Then technically there's a single source of data, it's just divided up.

Well the single source of data is the store.

The question is how that data gets to your components.

If you have a sufficiently simple hierarchy, you can just get the data from the store in your top-most component and pass it via props to children.

This gets rickety for sufficiently complex hierarchies or apps.

In those cases you can design your hierarchy so that parts of your data goes in to components further down the component hierarchy. However, you have to be careful that you're not exchanging one rickety design for another. You can avoid the confusion of data entering your app lower down the hierarchy by designing in such a way that you have a hierarchy of hierarchies where data just enters at the parent components of the sub hierarchies and making sure you have a logical bright line separating the different areas of your app where data enters.

Unsurprisingly, designing complex apps is complex.

# ? Dec 10, 2014 19:41

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

I'm goofing around with a Django-Rest-Framework -> React/Flux "fun" project (you've inspired me, Thermopyle!) and just want to get some opinions on how people would approach something. The app shows a list of Activities. A user clicks on one, and the details for said activities are displayed. So far, so good! Users can also sign up for Activities, and here's where my question lies.

Given that part of the details for an Activity is a list of other people who have signed up for it and possibly some other info about those users, getting the details is far more resource heavy than just getting the name and start date for it, which is all that's shown in the list. Users will rarely click on more than a few Activities, and there might eventually be a "large" number in the list. One option is that I can get the full details of every Activity into a single store up front, and just use that for everything. Another option is two stores, one for the list, one for the details view, with the list store only getting a "light" version of the object containing just the fields it needs that don't traverse any relationships and the detail store doing the "heavy" queries for participants and so on for just one object at a time. The third option is probably the smart one that I haven't thought of yet.

# ? Dec 18, 2014 03:22

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

Number 2 is how I'd handle it, but you need to have some way to ensure data remains in sync between the two. Its more or less a Activities store and an ActiveActivity store (bad name I know). The good thing about this is it provides a more focussed action structure, the Activities list would only need broader actions like delete activity, move, whatevs.

There's probably some stuff to do be done in there like caching Activity details so you don't have to hit the server for more if it already got that activity, but that really depends on the use case I guess.

# ? Dec 18, 2014 07:33

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

Lumpy posted:

I'm goofing around with a Django-Rest-Framework -> React/Flux "fun" project (you've inspired me, Thermopyle!) and just want to get some opinions on how people would approach something. The app shows a list of Activities. A user clicks on one, and the details for said activities are displayed. So far, so good! Users can also sign up for Activities, and here's where my question lies.

Given that part of the details for an Activity is a list of other people who have signed up for it and possibly some other info about those users, getting the details is far more resource heavy than just getting the name and start date for it, which is all that's shown in the list. Users will rarely click on more than a few Activities, and there might eventually be a "large" number in the list. One option is that I can get the full details of every Activity into a single store up front, and just use that for everything. Another option is two stores, one for the list, one for the details view, with the list store only getting a "light" version of the object containing just the fields it needs that don't traverse any relationships and the detail store doing the "heavy" queries for participants and so on for just one object at a time. The third option is probably the smart one that I haven't thought of yet.

I used to get hung up on this kind of stuff a lot more often.

Nowadays, I always get all of the things all of the time. I mean, it might be more resource heavy but I worry about that when it becomes an actual problem. Often it doesn't ever become a problem, and I saved myself the effort of additional code.

And by additional code I don't just mean the effort of writing more lines because that's barely anything. I mean the extra mental capacity taken up by having more logic to keep in your brain when reasoning about your code.

Thermopyle fucked around with this message at 18:47 on Dec 18, 2014

# ? Dec 18, 2014 18:45

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

Thermopyle posted:

I used to get hung up on this kind of stuff a lot more often.

Nowadays, I always get all of the things all of the time. I mean, it might be more resource heavy but I worry about that when it becomes an actual problem. Often it doesn't ever become a problem, and I saved myself the effort of additional code.

And by additional code I don't just mean the effort of writing more lines because that's barely anything. I mean the extra mental capacity taken up by having more logic to keep in your brain when reasoning about your code.

But I won't feel smart if I don't prematurely optimize! :smith:

# ? Dec 18, 2014 23:09

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

Lumpy posted:

But I won't feel smart if I don't prematurely optimize!

Oh, I definitely understand the compulsion. I've got to consciously take a step back every once in awhile to figure out if I need to be doing what I'm doing.

# ? Dec 18, 2014 23:37

Subjunctive: Sep 12, 2006; ✨sparkle and shine✨

Thermopyle posted:

the extra mental capacity taken up by having more logic to keep in your brain when reasoning about your code.

"Brainprint" is one of the most underestimated costs of optimization. Even where it's not much more code, it's usually harder to reason about.

# ? Dec 19, 2014 00:23

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

I'm wondering how I "add" and "remove" components in React. I've got a Search Form and a Search Results component, and I always want to display the Search Form, but only render the Search Results when the search button's clicked. Would it basically look something like this?

code:

  handleSubmit: function(event) {
    event.preventDefault();
    var results = searchPlaces(params);
    React.render(<SearchResults results={results}>, this.props.resultsEl);

# ? Dec 30, 2014 17:03

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

Pollyanna posted:

I'm wondering how I "add" and "remove" components in React. I've got a Search Form and a Search Results component, and I always want to display the Search Form, but only render the Search Results when the search button's clicked. Would it basically look something like this?
code:
  handleSubmit: function(event) {
    event.preventDefault();
    var results = searchPlaces(params);
    React.render(<SearchResults results={results}>, this.props.resultsEl);

JavaScript code:

var App = React.createClass({
  render: function () {
    var searchResults;
    if (this.state.results) searchResults = <SearchResults results={this.state.results} />
    
    return (
       <div>
           <SearchForm />
           {searchResults}
       </div> 
    )
  }
});

# ? Dec 30, 2014 17:47

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

Thermopyle posted:

JavaScript code:

var App = React.createClass({
  render: function () {
    var searchResults;
    if (this.state.results) searchResults = <SearchResults results={this.state.results} />
    
    return (
       <div>
           <SearchForm />
           {searchResults}
       </div> 
    )
  }
});

This is another semi-similar way:

JavaScript code:

var SearchApp = React.createClass({
     handleSearch: function () {
        // do a thing that searches
        this.setState({  searchResults: theResults });
    },
    getInitialState: function () {
        return {searchResults: []};
    },
    render: function () {
        return (
	   <div className="getMeIAmAWrapper">
             <SearchForm />
             <SearchResults data={this.state.searchResults} />
	  </div>
        );
    }
});

That way SearchResults can decide to be empty, decide to be hidden, or show a "there are no results to display" message all on it's own depending on if it has data or not.

# ? Dec 31, 2014 02:00

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

Yeah, that's the better way. I was just being lazy.

# ? Dec 31, 2014 02:13

Hed: Mar 31, 2004; Fun Shoe

This may be more of a back-end question, but ramifactions for asking are front-end. When designing a rest API, pay attention to the foreign key of category below:

JavaScript code:

[
   {
        "id": 1,
        "url": "http://sundown:8082/timekeeper/api/chargecodes/Holiday/",
        "category": "http://sundown:8082/timekeeper/api/chargecode-category/1/",
        "code": "Holiday",
        "description": "Company Holiday",
        "retired": null,
        "is_active": true
    },
    {
        "id": 2,
        "url": "http://sundown:8082/timekeeper/api/chargecodes/PTO/",
        "category": "http://sundown:8082/timekeeper/api/chargecode-category/2/",
        "code": "PTO",
        "description": "Personal Time Off",
        "retired": null,
        "is_active": true
    }
]

This hyperlinked relationship what seems to be the design suggested by using the Django Rest Framework tutorial so long ago. It's clear, not redundant and doesn't expect someone to "just know" how to find the chargecode category details. But some JSON API docs and the general fussiness of things like Angular and restangular to manage my relationships on the frontend seem to want something more like:

JavaScript code:

    {
        "id": 2,
        "url": "http://sundown:8082/timekeeper/api/chargecodes/PTO/",
        "category": {
                               id: 2,
                               url: "http://sundown:8082/timekeeper/api/chargecode-category/2/"
                             }
        "code": "PTO",
        "description": "Personal Time Off",
        "retired": null,
        "is_active": true
    }

(or replace url with href). This seems redundant and nested for no reason, but seems like the way more frontends want to work so I'm starting to question my REST end. I'd dearly like to use some other helper (like restangular) to help maintain state on the frontend instead of my cobbled-together code that kinda works now but how do you guys handle this?

# ? Dec 31, 2014 02:21

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

Hed posted:

This may be more of a back-end question, but ramifactions for asking are front-end. When designing a rest API, pay attention to the foreign key of category below:
JavaScript code:
[
   {
        "id": 1,
        "url": "http://sundown:8082/timekeeper/api/chargecodes/Holiday/",
        "category": "http://sundown:8082/timekeeper/api/chargecode-category/1/",
        "code": "Holiday",
        "description": "Company Holiday",
        "retired": null,
        "is_active": true
    },
    {
        "id": 2,
        "url": "http://sundown:8082/timekeeper/api/chargecodes/PTO/",
        "category": "http://sundown:8082/timekeeper/api/chargecode-category/2/",
        "code": "PTO",
        "description": "Personal Time Off",
        "retired": null,
        "is_active": true
    }
]
This hyperlinked relationship what seems to be the design suggested by using the Django Rest Framework tutorial so long ago. It's clear, not redundant and doesn't expect someone to "just know" how to find the chargecode category details. But some JSON API docs and the general fussiness of things like Angular and restangular to manage my relationships on the frontend seem to want something more like:
JavaScript code:
    {
        "id": 2,
        "url": "http://sundown:8082/timekeeper/api/chargecodes/PTO/",
        "category": {
                               id: 2,
                               url: "http://sundown:8082/timekeeper/api/chargecode-category/2/"
                             }
        "code": "PTO",
        "description": "Personal Time Off",
        "retired": null,
        "is_active": true
    }
(or replace url with href). This seems redundant and nested for no reason, but seems like the way more frontends want to work so I'm starting to question my REST end. I'd dearly like to use some other helper (like restangular) to help maintain state on the frontend instead of my cobbled-together code that kinda works now but how do you guys handle this?

I have only ever done it the 2nd way. I'm not entirely sure of DJANGO's reasoning behind the first. But I would say that if each ChargeCode "HAS A" Category, then category should be a sub/child object as per the 2nd example.

# ? Dec 31, 2014 15:25

aBagorn: Aug 26, 2004

HaB posted:

I have only ever done it the 2nd way. I'm not entirely sure of DJANGO's reasoning behind the first. But I would say that if each ChargeCode "HAS A" Category, then category should be a sub/child object as per the 2nd example.

Conversely, I've only ever done it more the first way. I always flatten objects server side before any client framework sees them.

# ? Dec 31, 2014 20:11

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

HaB posted:

I have only ever done it the 2nd way. I'm not entirely sure of DJANGO's reasoning behind the first. But I would say that if each ChargeCode "HAS A" Category, then category should be a sub/child object as per the 2nd example.

HATEOAS

# ? Dec 31, 2014 20:30

Asshole Masonanie: Oct 27, 2009; by vyelkin

Hi FED friends. My boss needs me to turn some legacy documentation for our web app that is some real old ASP.NET garbage into an angularJS app that is essentially the same thing; treeview table of contents sidebar that switches the content from section to section. I want to build it so it's a reusable framework, and has as few dependencies as possible. Currently the treeview TOC is a terrible html table that relates to arbitrarily numbered html files (that are some of the worst formatted crap from 2002, so I'd rather not continue using these same files). I'm trying to figure out the best way to reformat all these files into something clean and usable. I've been looking into some NoSQL type databases but have no idea which ones are worth trying to use. I was also thinking of just cramming everything into a JSON file but that seems pretty stupid to me.

So far I have an angular treeview plugin functioning, but it stores the treeview list in the actual programming which also seems dumb. So I'll need to be able to read the section/sub-section titles, article titles, and article content from wherever this data is stored. Is there some canonical way of doing this kind of activity that I'm totally overlooking? I thought about using mongoDB but I'd rather not have to install it on the server. Suggestions? Thanks y'all

# ? Jan 5, 2015 22:07

Spraynard Kruger: May 8, 2007

Man, that's a lot of things. I think your answer could depend on a lot of factors! How much documentation is there, how often does it change, does it interact with the web app at all, etc. If you need to update it frequently without doing a new code deployment, that could be a reason for a database, but otherwise I think you'd do fine with flat files. You don't have to cram it all into one, you could certainly split them into pages and load as necessary.

If this is your treeview, it doesn't look like they provide a method of loading via URL, so you would have to inject $http and snag the data yourself. Here's a quick and dirty Plunker: http://embed.plnkr.co/V1R1ra8gCyICr6CEFhoA

# ? Jan 6, 2015 04:45

aBagorn: Aug 26, 2004

Front end people, my humble middle stack self needs your help!

I'm using bootstrap to layout a site, and I came across this tutorial to implement an off canvas menu.

http://blog.themearmada.com/off-canvas-slide-menu-for-bootstrap/

Seemed simple enough, and I have it working in its basic form. However my client has indicated that he would rather (on desktop) the menu slideout shrink the main content div as opposed to overlaying it (though on tablet and mobile displays it should behave as normal) and now I'm kind of lost.

# ? Jan 6, 2015 15:59

spacebard: Jan 1, 2007; Football~

aBagorn posted:

Front end people, my humble middle stack self needs your help!

I'm using bootstrap to layout a site, and I came across this tutorial to implement an off canvas menu.

http://blog.themearmada.com/off-canvas-slide-menu-for-bootstrap/

Seemed simple enough, and I have it working in its basic form. However my client has indicated that he would rather (on desktop) the menu slideout shrink the main content div as opposed to overlaying it (though on tablet and mobile displays it should behave as normal) and now I'm kind of lost.

The nav element needs to be relative and not fixed. Here's a quick fiddle http://jsfiddle.net/0vwfj0x1/. I also needed to add a disabled class on the nav element itself.

# ? Jan 6, 2015 18:36

an skeleton: Apr 23, 2012; scowls @ u

I have a question. I'm a novice developer (been seriously developing for about a year or so) and I am finally feeling pretty proficient in AngularJS (I still kinda suck at creating directives from scratch but whatever). I kind of have the itch to learn a new JavaScript framework, I was thinking Backbone or Ember. However, I have 2 questions.

1) Is there a real plus to learning to different frameworks or should I just keep at one and if I ever have a serious need for the other, switch over?

2) What would you use Backbone for that you wouldn't use Angular for? Like is there a specific type of application that just screams Backbone? (ditto for Ember, I guess)

Of course the real answer to my question 1 is "just do it and find out you dickhead, you're still a newb" but I'd rather listen to internet strangers' theories. Thanks!

# ? Jan 7, 2015 05:32

Adbot: ADBOT LOVES YOU

# ? Apr 28, 2024 14:41

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

an skeleton posted:

I have a question. I'm a novice developer (been seriously developing for about a year or so) and I am finally feeling pretty proficient in AngularJS (I still kinda suck at creating directives from scratch but whatever). I kind of have the itch to learn a new JavaScript framework, I was thinking Backbone or Ember. However, I have 2 questions.

1) Is there a real plus to learning to different frameworks or should I just keep at one and if I ever have a serious need for the other, switch over?

2) What would you use Backbone for that you wouldn't use Angular for? Like is there a specific type of application that just screams Backbone? (ditto for Ember, I guess)

Of course the real answer to my question 1 is "just do it and find out you dickhead, you're still a newb" but I'd rather listen to internet strangers' theories. Thanks!

It kinda depends on your goal.

If you're wanting to expand your ways of thinking about the problems we encounter, I'd recommend learning React. Particularly because it's got a small API and you can read all the docs in one sitting, so it's not like you're devoting a big chunk of your life to it.

Really, the more you learn, the more tools you have to solve problems you encounter. They're all good to be familiar with.

# ? Jan 7, 2015 06:51

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

«‹›234 »