Club PA 2.0 has arrived! If you'd like to access some extra PA content and help support the forums, check it out at patreon.com/ClubPA
The image size limit has been raised to 1mb! Anything larger than that should be linked to. This is a HARD limit, please do not abuse it.
Our new Indie Games subforum is now open for business in G&T. Go and check it out, you might land a code for a free game. If you're developing an indie game and want to post about it, follow these directions. If you don't, he'll break your legs! Hahaha! Seriously though.
Our rules have been updated and given their own forum. Go and look at them! They are nice, and there may be new ones that you didn't know about! Hooray for rules! Hooray for The System! Hooray for Conforming!

[Programming] Thread: Fixed last bug in 5 month thread

19192949697100

Posts

  • NogsNogs Crap, crap, mega crap. Registered User regular
    edited August 2015
    basically i think that for whatever reason you might have a state or prop change flowing down through your entire app, and thus react is redrawing everything instead of the minimal amount.


    and yeah if you are doing forceUpdate, then it is very likely that is the case

    Nogs on
    rotate.jpg
    PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
  • urahonkyurahonky Registered User regular
    Well without the forceUpdate then it takes a few seconds to respond to button clicks (so if they click a delete button on a component then it would take a few seconds to disappear). But, like I said, I suspect that our app is probably setup differently than what most React apps are.

    When the component mounts then we hit an API endpoint to grab some data and then populate the state with that, when the data comes through then we do a forceUpdate and render the components. Then the user can remove/add components on the fly so it's really difficult to keep the shouldComponentUpdate working properly.

  • urahonkyurahonky Registered User regular
    If I had the time I'd love to go back and rewrite all of these components again for the tenth time. But we go live in 3 weeks and we have ZERO unit tests so if I change anything then we have to manually run through everything to make sure it doesn't break anything.

  • ecco the dolphinecco the dolphin Registered User regular
    edited August 2015
    Oh god my Javascript-fu is weak and fragile

    Me reading something registering to be a factory: Okay, you've called a function... that takes ... an empty... set of parameters I think.... and then an array of... arbitrary types some of which are themselves functions which also take empty parameters and there's another array of... *weep*

    Edit: At least the indenting makes this obvious! Yaaaay for indents!

    Edit2: Is this level of nesting a common style for Javascript/Web dev? Is this why I find lambdas in lambdas in lambdas in other places? =P

    Edit3: I mean, I get that it's ended up creating a whole anonymous type in the function call when registering to be a factory, but man. Maybe I would be more comfortable with TypeScript.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
  • admanbadmanb the bored genie Seattle, WARegistered User regular
    That much function nesting in JavaScript is usually because of how much async code it runs and how awkwardly it handles it.

    ecco the dolphinDelmain
  • djmitchelladjmitchella Registered User regular
    The problem with javascript is that it doesn't take objects very seriously, so there are a gazillion different ways to make it more OOP-like, and they are all different in varying ways and none of them quite work like objects in C++ et al, they just look like they do in ways that will confuse you to no end until you work out what's really going on. In particular, the way "this" doesn't mean the same "this" that "this" means in other languages can be a super big pain.

    ecco the dolphinurahonky
  • ecco the dolphinecco the dolphin Registered User regular
    edited August 2015
    Hahaha

    I'll say this for Javascript - it's a very flexible language. Perhaps too flexible for my personal taste, although I can certainly appreciate how it can be made to do almost anything...

    On the bright side, I've got my front end view requesting data via AngularJS, and now... I just have to wire it up to the EF back end.

    A year ago, I never thought I'd ever be saying anything resembling that sentence.

    Edit: Web dev skill level: Code monkey see, code monkey does. Still have much to learn. Cannot design at this stage, merely implement.

    ecco the dolphin on
    Penny Arcade Developers at PADev.net.
    urahonky
  • InfidelInfidel Heretic Registered User regular
    @ecco the dolphin doing web dev is going to bring me endless joy

    OrokosPA.png
    Play D&D 4e? :: Check out Orokos and upload your Character Builder sheet! :: Orokos Dice Roller
    The PhalLounge :: Chat board for Critical Failures IRC! :: #CriticalFailures and #mafia on irc.slashnet.org
    ecco the dolphinthatassemblyguyadmanbDelmaincrimsoncoyote
  • ecco the dolphinecco the dolphin Registered User regular
    Infidel wrote: »
    @ecco the dolphin doing web dev is going to bring me endless joy

    My career is like a bishop.

    It goes diagonally.

    Penny Arcade Developers at PADev.net.
    BarrakkethurahonkyDelmain
  • KambingKambing Registered User regular
    The problem with javascript is that it doesn't take objects very seriously, so there are a gazillion different ways to make it more OOP-like, and they are all different in varying ways and none of them quite work like objects in C++ et al, they just look like they do in ways that will confuse you to no end until you work out what's really going on. In particular, the way "this" doesn't mean the same "this" that "this" means in other languages can be a super big pain.

    It's not that Javascript doesn't take its objects seriously. It's that Javascript's prototype-based object model is fundamentally different from the traditional class-based object models found in Java or C++. It's very beautiful in its simplicity although I agree that the syntax of the language is deceptively similar to it's class-based cousins so that it's easy to get the two paradigms confused.

    @TwitchTV, @Youtube: master-level zerg ladder/customs, commentary, and random miscellany.
  • templewulftemplewulf The Team Chump USARegistered User regular
    Infidel wrote: »
    @ecco the dolphin doing web dev is going to bring me endless joy

    My career is like a bishop.

    It goes diagonally.

    What device will this website be embedded into?

    Twitch.tv/FiercePunchStudios | PSN | Steam | Discord | SFV CFN: templewulf
  • ecco the dolphinecco the dolphin Registered User regular
    templewulf wrote: »
    Infidel wrote: »
    @ecco the dolphin doing web dev is going to bring me endless joy

    My career is like a bishop.

    It goes diagonally.

    What device will this website be embedded into?

    ... touche, sir. Touche! =P

    Penny Arcade Developers at PADev.net.
  • NogsNogs Crap, crap, mega crap. Registered User regular
    javascripts strength and weakness is that it is insanely expressive.

    there is almost nothing it cant do. you can literally bend it to your will.

    but that also means you can end up with very very bad habits that "work"

    rotate.jpg
    PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
  • djmitchelladjmitchella Registered User regular
    Kambing wrote: »
    The problem with javascript is that it doesn't take objects very seriously, so there are a gazillion different ways to make it more OOP-like, and they are all different in varying ways and none of them quite work like objects in C++ et al, they just look like they do in ways that will confuse you to no end until you work out what's really going on. In particular, the way "this" doesn't mean the same "this" that "this" means in other languages can be a super big pain.

    It's not that Javascript doesn't take its objects seriously. It's that Javascript's prototype-based object model is fundamentally different from the traditional class-based object models found in Java or C++. It's very beautiful in its simplicity although I agree that the syntax of the language is deceptively similar to it's class-based cousins so that it's easy to get the two paradigms confused.

    Yeah, that's a better way to phrase things. The first (decent-sized) javascript project we worked on we used pure thing.prototype.doStuff() everywhere because it made it more obvious what was and what wasn't going on; there are many more ingenious approaches, but none of us had the instinct for javascript enough to want to do anything that wasn't really really easy to understand, and very unlikely to do anything unexpected.

    Kambing
  • InfidelInfidel Heretic Registered User regular
    edited August 2015
    We have arrived(ish) on a stack for one of our web apps. We need a mostly static and accessible front-end website for clients and purchasers, and a richer back-end application for admin/CSRs to manage accounts and authorizations and such. Some reports and visualizations for that latter one.

    So, we have moved away from Angular which my dev is very familiar with, since it is more suited to internal apps where you have target browsers and can make a lot more assumptions. We need that, yes, but I'd like to have these two web apps sharing a stack as much as possible to aid the devs and also because they will both need to communicate with some kind of black-box server behind them. All the domain data has to come from the black-box(es).

    Looking at doing React now, since isomorphic means I expect to be able to have components that could be reusable but mostly to have things consistent working on both apps, but having the front-end do server-side rendering for the page load and maybe having some client-side to do push rendering of a specific set of components (ticker, dashboard panels, etc.). The back-end app will be mostly client-side rendered and much more dynamic / one-page style.

    Choice of React here good, y/n?

    Trying to sort out the data that best suits this idea now. It will be [Client Browser] <=> [Web App VM] <=> [Data API VM (wrapping the database)] with the Web App VM swapping out per above.

    Lot of stuff to read up on lately, with Relay and Falcor and such.

    WHAT DO?!?

    (Thanks.)

    edit: also probably important, the "Data API VM" has to serve data not just by the session user but also by the Web App that is requesting, eg. the front-end app has less visibility into the data so that even a full compromise of the front-end Web App VM can't access certain data.

    Infidel on
    OrokosPA.png
    Play D&D 4e? :: Check out Orokos and upload your Character Builder sheet! :: Orokos Dice Roller
    The PhalLounge :: Chat board for Critical Failures IRC! :: #CriticalFailures and #mafia on irc.slashnet.org
  • NogsNogs Crap, crap, mega crap. Registered User regular
    edited August 2015
    isomorphic is a definite advantage.

    that being said, it is not as easy as using React.renderToString(). there is a lot more that goes on with it, especially if you have to fetch data server side.

    if going with react, i would strongly suggest looking at flux to handle app state and data. ideally a framework like alt, fluxible or redux that has async isomorphic solutions already. trust me, you dont wanna be handling state purely through react. ideally you would have "stateless" components that just recieve new props from flux stores that hold state. i think this might be one of the issues @urahonky is having, but thats just speculation on my part.

    react is reusable by nature, so its good for larger projects. i actually wouldnt suggest a person use react if doig a small website because the amount of initial work and boilerplate needed isnt immediately benefical nor speeds up dev.

    its when you get complex UIs and common patterns that the power of Reacts reusablity really shines.

    Nogs on
    rotate.jpg
    PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
  • zeenyzeeny Registered User regular
    Infidel wrote: »
    @ecco the dolphin doing web dev is going to bring me endless joy

    It will be fun the first time he causes a segfault!

  • zeenyzeeny Registered User regular
    edited August 2015
    Infidel wrote: »
    ... All the domain data has to come from the black-box(es).
    Looking at doing React now, since isomorphic means I expect to be able to have components that could be reusable but mostly to have things consistent working on both apps, but having the front-end do server-side rendering for the page load and maybe having some client-side to do push rendering of a specific set of components (ticker, dashboard panels, etc.). The back-end app will be mostly client-side rendered and much more dynamic / one-page style.

    Choice of React here good, y/n?

    It seems to be, but are you targeting mobile in any way?
    Other things to keep in mind: If you are all going to be learning the approach on the job, really make sure you can not rely on the technology you already have an expert it (ng) before switching to React. While I don't think that the approach is difficult in itself, experience says the first time always has unexpected bumps and if you have to deliver soon, it may not be worth it.

    Anecdotal: I'm aware of at least one case where an NG dev quit after a switch to React.
    Random: I genuinely believe that Reagent is the most accessible way there is to write/design React applications. http://reagent-project.github.io/ (doesn't mean it's the best....)


    Trying to sort out the data that best suits this idea now. It will be [Client Browser] <=> [Web App VM] <=> [Data API VM (wrapping the database)] with the Web App VM swapping out per above.

    Lot of stuff to read up on lately, with Relay and Falcor and such.

    WHAT DO?!?


    You don't need to go that way, Relay/Falcor are nice, but you are perfectly able to design a solid React application with a data flow you are more used to (standard backend split, even if you do rendering there).



    edit: also probably important, the "Data API VM" has to serve data not just by the session user but also by the Web App that is requesting, eg. the front-end app has less visibility into the data so that even a full compromise of the front-end Web App VM can't access certain data.

    ACL on frontend level(for display purposes) and enforcement on the backend (in case somebody tries to be smart) is relatively easy with https://en.wikipedia.org/wiki/JSON_Web_Token carrying permissions as part of payload or a similar strategy. Ask concretes if you run into a design roadblock.

    zeeny on
  • TryCatcherTryCatcher Registered User regular
    edited August 2015
    Man, haven't posted on this thread since forever.

    So, graduated, and managed to land a job. The pay is OK (for my country at least), and includes insurance and stuff.

    Is distance work of basically using Cordova (the free PhoneGap) to make a company app from a webpage, the whole thing is selling corporate solutions so is not a social media crapshoot, thank God. Office hours of being connected to the company chatroom and doing stuff on Netbeans (I like it), while using the company repository

    And it uses Ionic and Ionic-Material to give it that sleek phone app appereance while being a regular AngularJS webpage. Neat.

    TryCatcher on
    crimsoncoyotegavindelecco the dolphin
  • NogsNogs Crap, crap, mega crap. Registered User regular
    ive messed with ionic. prolly the best hybrid app framework out there.

    rotate.jpg
    PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
  • NogsNogs Crap, crap, mega crap. Registered User regular
    zeeny wrote: »
    Infidel wrote: »
    ... All the domain data has to come from the black-box(es).
    Looking at doing React now, since isomorphic means I expect to be able to have components that could be reusable but mostly to have things consistent working on both apps, but having the front-end do server-side rendering for the page load and maybe having some client-side to do push rendering of a specific set of components (ticker, dashboard panels, etc.). The back-end app will be mostly client-side rendered and much more dynamic / one-page style.

    Choice of React here good, y/n?

    It seems to be, but are you targeting mobile in any way?
    Other things to keep in mind: If you are all going to be learning the approach on the job, really make sure you can not rely on the technology you already have an expert it (ng) before switching to React. While I don't think that the approach is difficult in itself, experience says the first time always has unexpected bumps and if you have to deliver soon, it may not be worth it.

    Anecdotal: I'm aware of at least one case where an NG dev quit after a switch to React.
    Random: I genuinely believe that Reagent is the most accessible way there is to write/design React applications. http://reagent-project.github.io/ (doesn't mean it's the best....)


    Trying to sort out the data that best suits this idea now. It will be [Client Browser] <=> [Web App VM] <=> [Data API VM (wrapping the database)] with the Web App VM swapping out per above.

    Lot of stuff to read up on lately, with Relay and Falcor and such.

    WHAT DO?!?


    You don't need to go that way, Relay/Falcor are nice, but you are perfectly able to design a solid React application with a data flow you are more used to (standard backend split, even if you do rendering there).



    edit: also probably important, the "Data API VM" has to serve data not just by the session user but also by the Web App that is requesting, eg. the front-end app has less visibility into the data so that even a full compromise of the front-end Web App VM can't access certain data.

    ACL on frontend level(for display purposes) and enforcement on the backend (in case somebody tries to be smart) is relatively easy with https://en.wikipedia.org/wiki/JSON_Web_Token carrying permissions as part of payload or a similar strategy. Ask concretes if you run into a design roadblock.

    +1 on the JSON Web Token front.

    ya there are other things than flux even.

    backbone was actually a prefered data handler with react for a long time. could also check out firebase i suppose.

    id also agree to steer away from relay/graphql/falcor for now. all signs point to them being awesome, but they are still in tech-preview.

    rotate.jpg
    PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
  • Jimmy KingJimmy King Registered User regular
    Kambing wrote: »
    The problem with javascript is that it doesn't take objects very seriously, so there are a gazillion different ways to make it more OOP-like, and they are all different in varying ways and none of them quite work like objects in C++ et al, they just look like they do in ways that will confuse you to no end until you work out what's really going on. In particular, the way "this" doesn't mean the same "this" that "this" means in other languages can be a super big pain.

    It's not that Javascript doesn't take its objects seriously. It's that Javascript's prototype-based object model is fundamentally different from the traditional class-based object models found in Java or C++. It's very beautiful in its simplicity although I agree that the syntax of the language is deceptively similar to it's class-based cousins so that it's easy to get the two paradigms confused.
    One thing which I think people don't necessarily keep in mind is the history of JavaScript. While the history doesn't mean that it's great, it does explain a lot of the terrible bits and make some of it all the more impressive. To paraphrase part of a talk I saw by either Brendan Eich or Douglas Crockford (I think Crockford), JavaScript was designed from day one to only be a few lines of code here and there to make your gif move across the screen or whatever. A really, really, really big js program was intended to be 100 lines. That intention and assumption is why there are underlying architectural things which make these giant full on apps we do with it today get so messy so easily. Basically, we're using the wrong tool for the job every day (because there's not currently a correct tool for the job) and then wondering why it's painful.

  • bowenbowen How you doin'? Registered User regular
    The problem with JavaScript is that it's JavaScript.

    shit like type coercion (This shit is almost as bad as php's true/false/filenotfound and 0/null/exception)
    global variables (did you misspell poopyButt as poopy ? Well now poopy is a global variable, good luck!)
    shitty scope correctness

    There's a few dozen others.

    Plus it has a few gotchas. Semicolon placement is awkward and not required, sometimes. Sometimes it is. The language tries to figure it out. That's just stupid.

    Ladies.
    htm
  • TryCatcherTryCatcher Registered User regular
    I would like to mention that even dealing with JavaScript is still better than dealing with the slow, frustrating, crammed into Java, with resource hog IDEs crazy train that is native Android development.

  • bowenbowen How you doin'? Registered User regular
    edited August 2015
    Yeah I'll give you that. JS is way better than Java.

    Loads.

    I still don't know what this proclivity is to taking java programs and porting them to a website and using JS though, lots of people are doing it.

    I always hear scaling, but I can't really get behind that idea. You're taking local apps, which are essentially distributed computing and comparing them to centrally hosted apps, that often use one of the worst concurrency models.

    bowen on
    Ladies.
  • Jimmy KingJimmy King Registered User regular
    bowen wrote: »
    The problem with JavaScript is that it's JavaScript.

    shit like type coercion (This shit is almost as bad as php's true/false/filenotfound and 0/null/exception)
    global variables (did you misspell poopyButt as poopy ? Well now poopy is a global variable, good luck!)
    shitty scope correctness

    There's a few dozen others.

    Plus it has a few gotchas. Semicolon placement is awkward and not required, sometimes. Sometimes it is. The language tries to figure it out. That's just stupid.

    Yes, and that all stems from that it was intended to be a toy that you write 10 lines of, not thousands of lines across 50 different files. It doesn't make it any better for what we're doing with it, but explains it. It's about like being surprised that a Fisher Price drill in a kids toy toolset falls apart when trying to build a house with it because the motor isn't strong enough and the drill bits break and it doesn't quite fit your adult hands and faulting the tool for that. It doesn't have those things because it was never meant to be used in a situation where those things would matter. We just ended up doing so anyway and have painted ourselves into a corner where we now have no choice but to keep on using the wrong tool.

    bowen
  • bowenbowen How you doin'? Registered User regular
    Yup.

    I would rather have seen something like LUA with node instead of JavaScript.

    Just... anything but JavaScript come the fuck on.

    Ladies.
    htm
  • InfidelInfidel Heretic Registered User regular
    Thanks @Nogs @zeeny

    Not concerned very much about the React side of getting ramped up, I wanna figure out the stack asap though because the permanent dev hasn't been hired yet and I need to know what to look for there. :)

    Have been poking around at docs all last night and keep slicing things off until I reach something I like.

    OrokosPA.png
    Play D&D 4e? :: Check out Orokos and upload your Character Builder sheet! :: Orokos Dice Roller
    The PhalLounge :: Chat board for Critical Failures IRC! :: #CriticalFailures and #mafia on irc.slashnet.org
  • PhyphorPhyphor Building Planet Busters Tasting FruitRegistered User regular
    bowen wrote: »
    Yup.

    I would rather have seen something like LUA with node instead of JavaScript.

    Just... anything but JavaScript come the fuck on.

    It's a reinforcing cycle. The browsers only support js so everybody uses js which ensures the browsers will only support js

    Magic Box
    Academician Prokhor "Phyphor" Zakharov, Chief Scientist of China, Provost of the University of Planet - SE++ Megagame
    Delmain
  • bowenbowen How you doin'? Registered User regular
    Phyphor wrote: »
    bowen wrote: »
    Yup.

    I would rather have seen something like LUA with node instead of JavaScript.

    Just... anything but JavaScript come the fuck on.

    It's a reinforcing cycle. The browsers only support js so everybody uses js which ensures the browsers will only support js

    In Node's case... there was absolutely no reason to pick JavaScript, it's not really acting on the browser.

    Ladies.
  • DelmainDelmain Registered User regular
    bowen wrote: »
    Phyphor wrote: »
    bowen wrote: »
    Yup.

    I would rather have seen something like LUA with node instead of JavaScript.

    Just... anything but JavaScript come the fuck on.

    It's a reinforcing cycle. The browsers only support js so everybody uses js which ensures the browsers will only support js

    In Node's case... there was absolutely no reason to pick JavaScript, it's not really acting on the browser.

    it's because people wanted a server-side environment where they could use the same code they use on the front-end

    which meant they had to use js

    syndalis wrote: »
    Apple is a terrible company.
  • bowenbowen How you doin'? Registered User regular
    Fuck those motherfuckers then.

    Ladies.
  • urahonkyurahonky Registered User regular
    Nogs wrote: »
    if going with react, i would strongly suggest looking at flux to handle app state and data. ideally a framework like alt, fluxible or redux that has async isomorphic solutions already. trust me, you dont wanna be handling state purely through react. ideally you would have "stateless" components that just recieve new props from flux stores that hold state. i think this might be one of the issues @urahonky is having, but thats just speculation on my part.

    I'm just not sure how it's possible to have a stateless component if the user is actively interacting with it.

  • urahonkyurahonky Registered User regular
    Infidel wrote: »
    Not concerned very much about the React side of getting ramped up, I wanna figure out the stack asap though because the permanent dev hasn't been hired yet and I need to know what to look for there. :)

    Have been poking around at docs all last night and keep slicing things off until I reach something I like.

    React is a blast to use, personally. I used to be dead set against front-end development but I'm having more fun with React than I am with Python/Django.

  • NogsNogs Crap, crap, mega crap. Registered User regular
    urahonky wrote: »
    Nogs wrote: »
    if going with react, i would strongly suggest looking at flux to handle app state and data. ideally a framework like alt, fluxible or redux that has async isomorphic solutions already. trust me, you dont wanna be handling state purely through react. ideally you would have "stateless" components that just recieve new props from flux stores that hold state. i think this might be one of the issues @urahonky is having, but thats just speculation on my part.

    I'm just not sure how it's possible to have a stateless component if the user is actively interacting with it.

    by having state be handled by flux, using actions and the discpatcher to update flux stores which components listen to and recieve as props.

    rotate.jpg
    PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
    Infidel
  • urahonkyurahonky Registered User regular
    Nogs wrote: »
    urahonky wrote: »
    Nogs wrote: »
    if going with react, i would strongly suggest looking at flux to handle app state and data. ideally a framework like alt, fluxible or redux that has async isomorphic solutions already. trust me, you dont wanna be handling state purely through react. ideally you would have "stateless" components that just recieve new props from flux stores that hold state. i think this might be one of the issues @urahonky is having, but thats just speculation on my part.

    I'm just not sure how it's possible to have a stateless component if the user is actively interacting with it.

    by having state be handled by flux, using actions and the discpatcher to update flux stores which components listen to and recieve as props.

    Yeah we started looking at reflux but I had to abandon it for now since I just didn't have the time to research and use it. :(

  • gavindelgavindel The reason all your software is brokenRegistered User regular
    I somehow managed to set up a unit test that takes 13 hours to complete.

    ...But it passes, so all good, right?


    ecco the dolphinThe Anonymous
  • EchoEcho Moderator mod
    Echo wrote: »
    Let they who have not posted about their balls in the wrong thread cast the first stone.
    RendDisruptedCapitalistcrimsoncoyoteTofystedethThe Anonymous
  • bowenbowen How you doin'? Registered User regular
    Holy fucking shit. What is that even?!

    Ladies.
    DisruptedCapitalistgavindelironsizideThe AnonymousPolaritie
This discussion has been closed.