|
redleader posted:ui work is just global state management [citation needed] What's global about it? quote:redux is a way to add structure to global state manipulation so you can more easily understand it Understand what? Structure how? Here's how Redux ends up working in reality: 1. User navigates to the component that renders their fart log 2. The FartLogPage component dispatches a thunk function to fetch their 100 freshest farts 3. The thunk dispatches two actions: FETCH_FART_LOG_PENDING, then either FETCH_FART_LOG_SUCCEEDED with the response payload or FETCH_FART_LOG_FAILED with an Error 4. The reducer for the fartLog slice of the Redux state has a page of switch/case bullshit for mapping the previous fartLog state slice to a new fartLog state slice on the basis of these actions 5. Back on the FartLogPage there's a selector that pulls the fartLog state out of the Redux store, then renders a loading placeholder, a list of farts, or an error placeholder 6. Whenever the FartLogPage gets unmounted you have to... explicitly deallocate the fart cloud by dispatching a CLEAR_FART_LOG so that you don't have a cloud of farts hanging around wasting memory. Note that this is all completely distinct from a hypothetical individual fart's details page, then you have FETCH_FART_DETAIL times three plus a fartDetail state slice and so on. The user might navigate directly to a URL route for a particularly fondly remembered fart, after all. So that all has to be separate in the Redux store. Alternatively you could have a FartLogPage that does the fetching and then renders nothing but a FartLogView, which does the rendering. Just a single async method inside FartLogPage that fetches what it needs to fetch and stores it in component state. No action bullshit, no reducer bullshit, no selector bullshit, no explicit deallocation of local state. There's a redux-toolkit now that sort of cuts out some of this boilerplate but not really. I don't know what it is that Redux purports to cure but I think I'll keep the disease thanks.
|
#
?
Jun 20, 2020 02:28
|
|
|
|
| # ? Apr 19, 2024 23:37 |
|
|
if you don’t like global state then I have some bad news about databases
|
|
#
?
Jun 20, 2020 07:18
|
|
|
Soricidus posted:if you don’t like global state then I have some bad news about databases 
|
|
#
?
Jun 20, 2020 11:37
|
|
|
Sapozhnik posted:[citation needed] ui is a big sack of mutable, interlocked state. any interaction can affect the state of every single component, and any component can affect the workings of another component in non-obvious ways. it may not be the exact same as abuse of globals in c, but it's just as inscrutable and impossible to understand and work with above a certain level of complexity i can't really speak to the rest of your post since i don't like and am not experienced with ui dev. i've never used redux, and our app inconsistently uses vuex - as well as event buses and the normal store-state-on-parent-component thing. i've also had the privilege of dealing with 16000 lines of jquery running random frontend bits, using the dom as a state store if i was unlucky (i was usually unlucky) aiui the big advantage of the redux structure you described is that it's predictable and consistent. you won't be surprised to see how a component written by a different person/team/org works. i assume that these benefits become more significant as the complexity of the app grows. apparently the boilerplate becomes Just Fine once you've done it enough maybe i just need to work on a well-designed interfacebso i can learn from that, instead of just making GBS threads more state and methods into a couple of giant components god i hate ui i assume that the nerds at xerox parc solved the ui state management problem in the 70s and we're just waiting for someone to rediscover or reinvent their work
|
|
#
?
Jun 20, 2020 12:48
|
|
|
their secret was using smalltalk, where if you found something that was buggy you just fixed it in-ui and it would stay fixed the other path is fuzzing the ui w random input
|
|
#
?
Jun 20, 2020 14:51
|
|
|
Sapozhnik posted:Here's how Redux ends up working in reality: for some webshit react stuff I was building I looked at redux, saw that boilerplate, and used mobx and mobx-react instead.
|
|
#
?
Jun 20, 2020 20:12
|
|
|
terrible programmer: chose a framework and language i hardly know over what i do out of sheer boredom
|
|
#
?
Jun 20, 2020 20:35
|
|
|
peeps already whacked a couple tries into in browser rsbms didnt they current dealios are not really good enough but lol
|
|
#
?
Jun 20, 2020 21:31
|
|
|
Drastic Actions posted:for some webshit react stuff I was building I looked at redux, saw that boilerplate, and used mobx and mobx-react instead. I recommend everyone to look into react hooks, specifically useContext and useState for all your state management needs. We've found it much more straightforward than the frameworks.
|
|
#
?
Jun 20, 2020 21:39
|
|
|
Actually that's not even the biggest problem with Redux. The literal pages of boilerplate for every single CRUD operation do get kind of old after the third or fourth (or fifteenth...) time you have to bash them out in a single project and begin to idly wonder if this Redux poo poo might perhaps not be mankind's greatest invention ever. It's the fact that it's a gigantic ball of global variables holding the entire state of your application, and every component that interacts with it (which is most components) is a function of the entire thing. This is CRAZY. How the hell do you look at that and say "This is fine."
|
|
#
?
Jun 20, 2020 21:58
|
|
|
Sapozhnik posted:Actually that's not even the biggest problem with Redux. The literal pages of boilerplate for every single CRUD operation do get kind of old after the third or fourth (or fifteenth...) time you have to bash them out in a single project and begin to idly wonder if this Redux poo poo might perhaps not be mankind's greatest invention ever. as someone dabbling a bit with react development I've been asking the same question but before reading you saying it I just assumed I'm dumb and that I don't really GET ui dev
|
|
#
?
Jun 20, 2020 22:33
|
|
|
well the blog posts introducing redux were talking about it being functional programming and stuff, so webdevs jumped on the bandwagon since fp is cool and extremely sciencey and looks good on their faang application
|
|
#
?
Jun 20, 2020 22:51
|
|
|
Sapozhnik posted:Actually that's not even the biggest problem with Redux. The literal pages of boilerplate for every single CRUD operation do get kind of old after the third or fourth (or fifteenth...) time you have to bash them out in a single project and begin to idly wonder if this Redux poo poo might perhaps not be mankind's greatest invention ever. IIRC Redux was cargo culting whatever elm was doing. elm is a functional language and works very well with that pattern (even when you have nested things and components written by other people etc...). however javascript is javascript, and therefore you get what you get.
|
|
#
?
Jun 20, 2020 23:19
|
|
|
redux was an insanely overcomplicated solution to a difficult problem in earlier versions of react and flux sucks now you should probably just use hooks
|
|
#
?
Jun 20, 2020 23:22
|
|
|
Hooks suck as well and I'm not regretting my decision to stay well away from them in my personal projects so far. I don't need a bunch of weird quasi-language-features for the sake of saving a few lines of code per component. An idiomatically-written function component is pure, a class component is not. Class components are instantiated, receive lifecycle events like mounts and unmounts, and hold their own state that they update using this.setState (which in turn may trigger a re-render). None of this is React-specific and your basic imperative programming intuitions are going to be valid for this arrangement. There are plenty of organic non-React constructs that you can build on top of this as well that don't have weird usage rules; for instance, if you want to sort and categorize a list that you receive from props then you can do something like "sortAndCategorize = memoize((rawInput) => { ... });" in the class body and then call "this.sortAndCategorize(props.whatever)" in the render function. If you need to store or update some state you can call this.setState() instead of having some insane system where you call useState() seven times and each call of useState() gives you access to a different hidden state variable for that particular "instantiation" of a function. The new and stabilized React context mechanism is a fine and dandy way for deep passing of shared state without all the mess associated with Redux. You either use the provider/consumer component pairs that React spits out, or even better, just use the provider component and declare right there in your class which one piece of ambient context a given class consumes (which is going to be something slightly narrower in scope than "literally the entire universe") with a static contextType. If your component needs to simultaneously consume two bits of ambient context then you very probably have a bad design on your hands. It's a terrible shame that React's new concurrent mode stuff only provides hooks instead of a more traditional class component mechanism alongside it, because the concurrent mode bits are really cool. But then every webshit developer behaves like a cat chasing a laser pointer so I guess I shouldn't be surprised.
|
|
#
?
Jun 20, 2020 23:39
|
|
|
Hooks are just the developers getting bored with MVU and moving towards FRP.
|
|
#
?
Jun 20, 2020 23:49
|
|
|
just write backend, op
|
|
#
?
Jun 21, 2020 00:33
|
|
|
there are aspects of hooks I find compelling from an API front but when you break down the "how we got here" part it is just incredibly grim i do appreciate that dan abramov is pretty honest about like "yeah i didn't think anyone would really use redux for this long i thought someone would build something that sucks less by now." i think if he hadn't moved onto react core we would have gotten something more like redux-toolkit sooner which helps a lot we use redux+sagas in our codebase and it's the largest app i've ever worked on and i absolutely hate it; our patterns are awful and i keep trying to present a refactor proposal but get stymied by just how difficult it is to fix (also i hope dan figures out his visa situation so he can quit facebook cuz he's a very smart dude who i have to imagine does not really want to be working on react anymore)
|
|
#
?
Jun 21, 2020 02:22
|
|
|
can someone recommend a react tutorial? i want to take one more stab at it
|
|
#
?
Jun 21, 2020 02:23
|
|
|
Sapozhnik posted:The new and stabilized React context mechanism is a fine and dandy way for deep passing of shared state without all the mess associated with Redux. You either use the provider/consumer component pairs that React spits out, or even better, just use the provider component and declare right there in your class which one piece of ambient context a given class consumes (which is going to be something slightly narrower in scope than "literally the entire universe") with a static contextType. If your component needs to simultaneously consume two bits of ambient context then you very probably have a bad design on your hands. this is about where i've landed; I use context or occasionally something like a form library that wraps context if I'm lazy. my last app, greenfield and small in scale, was "vanilla" React + Formik for forms (which I think is now all-in on hooks and I'm not sure how it is these days) and it was really nice since I had a very shallow app and rarely needed to worry about passing data down into very-nested stuff also I now use Vue for personal projects lol; Vue 3's composition API seems to be like hooks with an easier-to-reason-about form of magic (reactive proxies) and I'm looking forward to it making it easier to use TypeScript with Vue
|
|
#
?
Jun 21, 2020 02:25
|
|
|
Shinku ABOOKEN posted:IIRC Redux was cargo culting whatever elm was doing. elm is a functional language and works very well with that pattern (even when you have nested things and components written by other people etc...). however javascript is javascript, and therefore you get what you get. the thing that bums me out most about redux is it failed to include the "commands" aspect of the Elm architecture, which in Redux terms is "what if reducers could dispatch further actions as part of their return value?" it means you can avoid the thick action creator layer almost all Redux apps have (see: sagas, etc) there were a couple stabs at doing this (redux-cycle being the biggest I think) but I don't think they got much adoption
|
|
#
?
Jun 21, 2020 02:28
|
|
|
PIZZA.BAT posted:can someone recommend a react tutorial? i want to take one more stab at it https://vuejs.org/v2/guide/
|
|
#
?
Jun 21, 2020 02:41
|
|
|
Vue is yet another iteration of the same MVCrap we've been plagued by for the past two and a half decades of web development and it's still crap for all the usual reasons why MVC is crap. There is no meaningful separation between your HTML, the imperative code mangling that HTML, and the object graph that passes data between the two, it's an attempt to create a separation of concerns where none exists. You've got loops, you've got conditionals, you've got an expression language (which at least sometimes is just the host language expression syntax), you've got reusable chunks of code like, what shall we call these... hmm... how about "functions". You could create yet another lovely castrated language alongside your existing well-developed programming language for no good reason, or you could just make trees of HTML elements (or a lightweight equivalent thereof) into a first-class data type for the language you already have and call it good. Boggles my mind to think somebody could go back to what really ought to be a discredited way of doing UI by now after spending any sort of serious time working with React.
|
|
#
?
Jun 21, 2020 02:53
|
|
|
Is it time to go back to server-side rendered templates and javascript for progressive enhancement yet? Can it be in not-nodejs?
|
|
#
?
Jun 21, 2020 12:51
|
|
|
a lot of pages have some sort of progressive enchantement going, they're mostly readable without javascript. at this point i would be happy if there were more pages that just hosted all the javascript they require to work. so bored of adding an exception to ajax.googleapis.com in umatrix just so the page is able to lazily load the images
|
|
#
?
Jun 21, 2020 13:37
|
|
|
I hate templating. I used to think i liked it which is why i put off react for so long. but now I'm using it and it's better in every conceivable way.
|
|
#
?
Jun 21, 2020 13:54
|
|
|
Gaukler posted:Is it time to go back to server-side rendered templates and javascript for progressive enhancement yet? Can it be in not-nodejs? i never stopped, razor 4 lyfe (also asp.net mvc is literally the only thing I know how to do)
|
|
#
?
Jun 21, 2020 18:42
|
|
|
One of my applications has a server-side template with a <template> element in it 
|
|
#
?
Jun 21, 2020 19:41
|
|
|
Gaukler posted:Is it time to go back to server-side rendered templates and javascript for progressive enhancement yet? Can it be in not-nodejs? sorry, the hype du jour at hacker news is next.js which is literally server-side render templates... in react... so you can use node js with it! 
|
|
#
?
Jun 21, 2020 19:51
|
|
|
Bloody posted:jIrA iS sO sLoW iTs UnUsAbLe well yeah your orgs customizations have ballooned the `issue` table to 10,000 columns no poo poo its slow wait, jira customizations don’t create their own related tables, they just dump everything into one? JFC
|
|
#
?
Jun 21, 2020 20:02
|
|
|
eschaton posted:wait, jira customizations don’t create their own related tables, they just dump everything into one? joins are slow 
|
|
#
?
Jun 21, 2020 20:24
|
|
|
Powerful Two-Hander posted:i never stopped, razor 4 lyfe server-side rendering is so easy and good. it's what the web was designed for in the first place lol
|
|
#
?
Jun 21, 2020 23:36
|
|
|
NihilCredo posted:sorry, the hype du jour at hacker news is next.js which is literally server-side render templates... in react... so you can use node js with it! My company already uses this and I feel like I’m taking crazy pills. Our frontend web servers just run node/nextjs to render react, and themselves call a bunch of go microservices that talk to the database/other data stores. We insert the terrible node build process and an extra, slow layer in the middle of our architecture for dubious effect.
|
|
#
?
Jun 22, 2020 08:43
|
|
|
For my toy projects I've been using Phoenix LiveView. The last project was minesweeper and it was a joy compared to my old stack of php/angular. Essentially it's SSR with normal Phoenix templates with a small JavaScript process added on. As you bind elements with things like phx-click it sends a websocket request to the backed. This is just a call back that returns a new template. The JavaScript gets this and hot swaps the DOM. Theres two lines in my App.js, it's wonderful.
|
|
#
?
Jun 22, 2020 09:00
|
|
|
eschaton posted:wait, jira customizations don’t create their own related tables, they just dump everything into one? they also dont really have internal hooks in the API, they get most of their data from internal REST calls
|
|
#
?
Jun 22, 2020 13:30
|
|
|
eschaton posted:wait, jira customizations don’t create their own related tables, they just dump everything into one? surprised they don’t just dump everything into an EAV table susan b buffering fucked around with this message at 13:43 on Jun 22, 2020 |
|
#
?
Jun 22, 2020 13:36
|
|
|
redleader posted:server-side rendering is so easy and good. it's what the web was designed for in the first place lol I've seen people advocating this, as a backlash against the whole Backbone / Ember / Angular eventually React wave. Are you guys doing traditional MVC? Like, ASP.NET, jsf? There's a lot of pain there that got mentioned up-thread. What modern server-side rendering are people doing that's a great developer experience? I guess I've heard things about Phoenix on Elixir, which looks like MVC without all the baggage of historical bad decisions. i'm focusing on developer experience because server-side rendered is clearly better for users most of the time, but nobody making technical decisions gives a poo poo about users from my variety of career experience across multiple different industries.
|
|
#
?
Jun 22, 2020 14:31
|
|
|
code: e: Django is fine. Its ORM is the least loathesome and most sites I need to make are basic CRUD stuff that I only write a few hundred LOC for anyway. Antigravitas fucked around with this message at 14:57 on Jun 22, 2020 |
|
#
?
Jun 22, 2020 14:55
|
|
|
Twerk from Home posted:I've seen people advocating this, as a backlash against the whole Backbone / Ember / Angular eventually React wave. the only pain w/ mvc or mvvm is self inflicted. don't gently caress it up with javascript and you'll be fine
|
|
#
?
Jun 22, 2020 15:02
|
|
|
|
| # ? Apr 19, 2024 23:37 |
|
|
is knockout still a thing that people use for mvvm on web? i liked that. you could almost get away with no js at all beyond defining your viewmodel properties and maybe a couple of ajax calls
|
|
#
?
Jun 22, 2020 15:06
|
|