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

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

There is a heppy lend
Fur, fur aw-a-a-ay.

PlesantDilemma posted:

Someone needs to do a newbie-friendly write up of RequireJS because I don't really understand it but it gets a lot of buzz. If I use RequireJS, I know I get to define what a script depends on and have a way to describe it in my code, so that has value. But I don't get how it brings in those depends. Does it compile everything into a big .js file with all my stuff? Or does it generate <script> tags to bring them in at run time? Right now we just have grunt concat and min all our stuff, but deciding the order that everything should be concat-ed was a headache.

It does generate script tags, though in practise there'll only be a single compiled file (the grunt requirejs plugin take over from what concat is doing now). Then you've the control over order and dependencies all nicely baked together. Here's the current dev version of of a site I've just started doing (sorry, it's a poo poo example as no actual modules have been written yet), with all my scripts injected via require.js:



and here's a quick production version, compiled:



The requirejs file is in the footer, but I could use almond to remove the need for it altogether; at the minute it runs require, which then injects my compiled main.js into the head.

I generally do website development, not apps, so my needs are a bit more basic than if I were using frameworks heavily, but I can't recommend require enough.

----

On frameworks, Ractive seems very, very good if you need something fairly simple. Just worked through the tutorials. Well written and engaging, which generally swings things for me, plus ractive was built for practical use by The Guardian, so it's somewhat battle-tested.

Adbot
ADBOT LOVES YOU

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Pollyanna posted:

I'm absolutely not doing it by convention at all simply by trying to work Ember into Middleman's structuring. There's no official support for Ember like there is with Rails, so I kinda have to work from the ground up. I'm tempted to port my site to Rails, though, cause of how much of a pain it is :(

There's no 'official' support for Rails either, you're just swapping one problem (issues caused by not following the conventions of opinionated framework a. and instead attempting to jam it into opinionated framework b.) for another one (issues caused by not following conventions of opinionated framework a. and instead attempting to jam it into opinionated framework c.); the ember-rails gem was last updated 3 months ago, ember-appkit is dead, &c &c &c. Middleman should make it easier to do what you want to do because it's an extremely simple application with fewer conventions to [learn how to safely] circumvent.

What you're doing's more than possible and not particularly difficult (it.is.just.easier.to.keep.things.separated). You're just exacerbating your issues by trying to combine multiple other flavour-of-the-month technologies.

Note that I don't know poo poo about Ember, and maybe there's some magic gem I couldn't find that glues Ember CLI functionality into Rails and scaffolds and builds your entire app to match [insert arbitrary tutorial]. poo poo, I like playing around with new stuff, but honestly

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Ahz posted:

I did the JS fallback to png:

onerror="this.onerror=null; this.src='{% static 'img/logo_dark_pink_graphic.png' %}'"

As long as it's a very small image (as it d/ls twice on some browsers), you can put the PNG in an <image> tag inside in an SVG element with, an href pointing to to the SVG and a src pointing to the PNG, no js needed; older browsers ignore the SVG and correct <image> to <img>

RobertKerans fucked around with this message at 07:07 on Sep 16, 2014

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Ahz posted:

So this is both items in the same html tag, or am I editing SVG metadata?

pre:
<svg>
  <image xlink:href="svg.svg" src="svg.png"/>
</svg>
That's it.

See http://css-tricks.com/svg-fallbacks/, it works really very well. You're using the SVG as an image regardless (so no manipulation via CSS etc*), it just has to be wrapped in an SVG tag. Older IE/Android ignore the <svg>, read the <image> as an <img> tag and ignore the href attribute, compliant browsers read the <image> tag correctly and ignore the src attribute. IE requests both, other browsers don't.

*one plus of this hack; if you do need that, then inline SVG works fine - the <image> tag just then just needs a 'src' attribute, leave off the 'xlink:href'.

RobertKerans fucked around with this message at 22:15 on Sep 16, 2014

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

If nothing else, learn Backbone for the tiny, heavily commented and very understandable codebase, it's a good codebase to read. It's not a complicated framework at all (effectively just a collection of helper methods), and you can pick it up very quickly. Also, it is easy to pair it (replacing Backbone views) with the equally non-complex React (or Ractive, for that matter).

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Eg you want Elixir's pipe operator. I hesitate to do this, but here's another thing you can learn http://livescript.net/. You are trying to replace chaining with chaining that looks more like Elixir/Haskell/F#/Scala and doesn't quite work the same because the language is not built to easily do the thing you want to do. The Gulpfile should be a simple config file, you don't need to do this

RobertKerans fucked around with this message at 11:55 on Feb 5, 2015

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Pollyanna posted:

What employer and coworkers? I'm not even employed quite yet. And besides, I'm not actually going to implement this, it's just a thought experiment (unless somebody does want me to make it in which case I was completely serious).

I would like to be able to write Elixir/Erlang, and have access to something along the lines of clojurescript/scalajs. I'm happy to just have a macro based solution, so you'd could do something like have a hard dependency on sweet.js (and node, unfortunately), just until you can redo the compiler in Erlang/Elixir. Please make the DSL as close as is possible (maybe abstractions over web workers emulating processes, that kinda thing). Thanks! ;)

RobertKerans fucked around with this message at 22:54 on Feb 5, 2015

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.
Grunt/Gulp are fantastic for design, where a fairly large set of scripts all doing specific things to a prototype are necessary. But for most dev tasks, yeah, NPM scripts are generally better.

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

prom candy posted:

It's the Wild West because we also have to keep up with UI/UX trends in order to be as user friendly AND unique as possible. I loving love it though.

It not even trends per se. If you're building frontend, it isn't completely reducible to a logical input -> output, it is part aesthetic and you can't really remove that part without making poo poo, that's when you get the "clearly built by a backender" style interfaces. Some poor shmuck has to actually use the interface, rather than a computer. Smoothness, animation, timing of responses and indicators, a million and one other tiny things; they're pretty irrelevant to how a computer would deal with things, and they're hard to get right. Not harder than anything else, just different problems (maybe sometimes perceived as all just horrible untestable messy side effects?)

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.
This is a long shot, but is there any sensible way to prevent rerendering the entire collection held in the state of React Context when I update part of it? My state looks like this:

code:
{
  someID1: {
    foo: 1,
    bar: 2,
 },
 someID2: {
   foo: 1,
   bar: 2,
},
....lots and lots more
And elsewhere in the app, I have something like:

code:
const Alerts = () => {
  const alerts = useContext(AlertsContext);

  return (
    <figure>
      {Object.entries(alerts).map(([id, alert]) => (
        <AlertOverview key={id} {...alert} />
      ))}
    </figure>
  );
}
When I update one of those alert objects, or add more alerts, it updates the state in the Provider, which then goes to that Consumer, which then naturally just rerenders everything. At first I thought I could forcibly prevent rerendering (via componentshouldUpdate or React.memo) on the <AlertOverview /> components themselves, but that doesn't work (the whole state seems to be assumed to be new, so no dice). React.createContext takes a second [callback] argument, calculateChangedBits which seems designed to deal with this exact issue, but it's unstable and involves bitmasks and tbqh I don't see how I can apply it to my usecase

RobertKerans fucked around with this message at 16:39 on Jan 30, 2019

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.
I'm taking over work on a React Native app, and all over it is this pattern:

code:
mapState = state => ({ foo: state.foo })

mapDispatch = dispatch => ({ getFoo: () => dispatch(getFooAction()) })

class SomeContainer {
  constructor() {
    this.props.getFoo();

    this.state = {
      foo: []
    };
  }

  componentWillRecieveProps(newProps) {
    this.setState({ foo: newProps.foo });
  }

  render() {
    { someCheckOnFoo ? <SomeComponent foo={foo} /> : <ZeroStateComponent /> }
  }
}
It's a pretty big app, with a load of screens that all pull in data, so this is everywhere, like a rash. I get why the people who originally built the app did it, and at first glance it kinda does make handling missing data or data that's still coming in over the wire a bit easier (?). But notwithstanding the fact CWRP is aliased as `UNSAFE_` and has usage warnings all over the docs, is this at all a common or sensible pattern? It seems, if nothing else, that duplicating the state of the relevant Redux store slice in every container component is a massive footgun

edit: aargh, and they've used some boilerplate-reducing library that obfuscates the redux actions/reducers, and all the reducers are all in one ~1500 line file

RobertKerans fucked around with this message at 14:03 on Feb 28, 2019

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

prom candy posted:

You should definitely undo this pattern as it's dumb and also relies on lifecycle methods that are going to be deprecated. Sounds like a real pain in the rear end, sorry!

Fanks, just needed some basic justification that what I was staring at was actually dumb and it wasn't some secretly common pattern that had appeared in the two years I haven't been doing React.

Oh god, and it looks like they've tried about 20 bajillion different approaches to styling the loving thing and now I can't figure out how the hell to use the font they've used for the rest of the app in the new views I've got to build. And it's two react-native minor versions and god knows how many patch version behind. Oh I love agencies, I now have to take all this and spend the next few months bringing it in-house

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.
Not quite as bad as it could have been tho. We hired an agency to build the app initially, and then I was hired ~8 months in to bring it in-house once we had MVP; technically they're still building the app (tho I think we've brought it down to half a dev a week in terms of paying them, and they're basically just bugfixing atm), so I can at least quiz the guy who did most of the work on why he made the decisions he did before we wave bye bye to them.

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Ruggan posted:

So what’s the right way to structure this?

I’m assuming they built it to load data, stuff that in a reducer, and put said data into local state for editing or something.

If the local state serves no real purpose and is truly duplication then sure that’s moronic and you should just reference the props directly. Detangling that might be a huge pain in the rear end. But if it’s loading redux data into local state for an editable form it makes sense to me?

I just want to make sure I understand what part of it is terrible so I can avoid it in my own code.

That would be ok! And in fact one part of the app does have a fairly lengthy form. And that form does make use of data in the store/remotely.

But the actual local data doesn't get edited in that case, only read. The pattern is used everywhere in the app, and in the main, the app is just displaying info grabbed from various endpoints. It looks like it is the developer's go-to solution for handling loading of remote data & keeping the UI in sync. I might be wrong on that and I need to quiz him about it when he's back next week; he's quite experienced and he'll definitely have, at least, a sensible-at-the-time reason for doing it. Even if that reason is "I've had problems keeping data in sync on previous apps & this happened to work really well for me", that would be OK. But I still think there's going to be a helluva lot to untangle. The app seems far too complicated, and the more I read through the code, the more I can see how layers of cruft have built on top of each other.

Ugh and this app is giving me a deep and unbridled hatred for any library that claims to DRY up redux by abstracting over actions/types/reducers. Redux boilerplate is fine: it's brutally simple, easy to test and really obvious, there's no need to hide it to save a few keystrokes, stop making it complicated already

RobertKerans fucked around with this message at 11:07 on Mar 1, 2019

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Vincent Valentine posted:

My biggest concern with redux boilerplate isn't laziness or anything like that, it's that there's up to 4 places where a single piece of state is managed between Selector/Reducer/Action/Type. Having so many different things dictating how one single thing works gives you a lot of places to introduce mistakes. I agree that you shouldn't be using any libraries to simplify the process, however. If someone doesn't like Redux's boilerplate to the point that they want to install another library, another state management system is probably the correct choice.

That being said though wanting to reduce the redux boilerplate is a worthy goal, one that has spawned a lot of great state management systems over the course of just a couple of years.

Yeah, I do definitely understand avoiding splitting across files, and it does give me headaches. Reducing edit distance is a generally good thing: eg React components, with the direct representation of the output alongside the logic, are great. But although redux code does spread across files, the way the boilerplate interlinks does provide some level of protection. re abstractions over the whole thing: with types, I really don't like them being generated, as that implies strings, which then implies my app may not instantly explode (+ my editor is not going to scream at me) if I type something wrong. Then situations where the reducers aren't segregated into individual files that represent discrete state slices is pretty annoying. As is avoiding switch statements; given Redux is a state machine that switches states based on input messages, using the syntax explicitly designed for that seems sensible but whatever. Actions and selectors are the two ones where there is the most opportunity for programmer error that isn't very easy to locate I guess. The sheer simplicity of actions kinda guards against that though.

RobertKerans fucked around with this message at 15:25 on Mar 1, 2019

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

my bony fealty posted:

useReducer and useContext are becoming my favorite thing in React. the only problem is trying to control components rerendering all the time when you don't want them to, which has not proved to be a big problem yet but certainly will at scale. anyone have suggested resources for learning about this kind of thing? should I be looking at memoizing components?

YMMV, your usecase/setup might be completely different and it might work fine, so go ahead and just try stuff, but:

I'm gonna guess at somewhere you have a collection of stuff: that's going to be your issue. Memo ain't any use (directly) for that (isn't really much use for context stuff), and you're going to have to do some very funky stuff to get it working optimally. I rebuilt one of the smaller apps at my work, replacing redux with context. Pretty simple, normalised model, was very careful about what parts I wanted to update, split across multiple providers, still getting unwanted re-renders all over the place. Rerenders are pretty cheap, so not a massive issue, but couldn't optimise them away, went back to redux.

Context is really good for stuff where you have a few states known in advance (eg theme switching, auth). Context is really not so good for stuff like collections, and isn't currently designed to be. There is a second argument you can give to createContext (unstable_observedBits) that allows you to do optimisations via bit flags, so they're clearly thinking about how to fix stuff. react-redux hit this issue (among others) when they switched to using context, and they're ripping context out ATM and reverting back to how it worked before

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

SimonChris posted:

What's the problem, specifically? I am using Context to pass down my shared state, including a bunch of lists, and I haven't noticed any issues. Is it just a performance thing?

Yeah; just for context (heh) I am making a direct comparison with redux, as in replacing that with Context, and I ran into perf problems pretty quickly. The issue was the diffing of the state object, and the fact that Context is completely dumb. Any change to that object triggers rerenders to all subscribed consumers in the state tree. Memo doesn't help at all because it uses shallow comparison. I found I was basically trying to duplicate what react-redux already does better (use a fairly complex battery of methods to decide which parts of the state have to update) and having to write sometimes quite complex logic in components to prevent them rerendering unecessarily.

It's all contextual, and I hope over this year they work on improving it because I would love to be able to strip out redux. The DX is great; in the app I rebuilt, I got it down to 4 dependencies (react, react-dom, then the app-specific aws-amplify, and history for basic routing), hacked out a few thousand lines of code, and the code I rewrote was much simpler (until the diffing logic started to get gnarly). I'd really like to be back in that position, if only from a maintenance pov, and if the performance thing isn't an issue I'd totally recommend it.

RobertKerans fucked around with this message at 14:44 on Mar 15, 2019

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Thermopyle posted:

Has anyone read about any work being done to bring chrome's devtools css grid functionality up to par?

I prefer to use chrome's devtools as I'm working, but Firefox does a way better job debugging css grid...

Just found this Chrome extension: not quite same usecase (not just simply debugging, it's a design tool) & and not close to Firefox grid tooling yet, but my first impression is that it's very good & it's definitely extremely slick. The developer who built it now works for the Chrome team as CSS advocate (and the extension looks to have been taken over as a Google thing?), so I'd guess it would be worth keeping an eye on.

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

prom candy posted:

They switched to calling them "function" components instead of "functional" as well because the hook stuff I guess makes them not truly functional or something I dunno I don't have a CS degree

I dunno, I think it just makes more sense to call them function components given that's what they are, calling em "functional" just seems a bit opinionated. Hooks seem to basically be algebraic effects afaics from skim reading this paper that is the first result on Google, and they're functional things, but I also do not have a CS degree so

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Scaramouche posted:

The Cavern of COBOL > Modern front-end development: I also do not have a CS degree

The Cavern of COBOL > Modern front-end development: Does ignorance of history mean we are doomed to repeat the mistakes of the past for all eternity?

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Lumpy posted:

VIM emulation. That’s it.

I get the autocomplete giving up every so often. I don't get the fans issue, but I do get cmd-v just flat out not pasting sometimes. Afaics it's the vim plugin. But I like vscode too much to switch away from it and I like having the vim plugin too much to disable it so I just put up with it occasionally being a pain in the rear end :shrug:

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Doom Mathematic posted:

You mean like Times New Roman?

Yeah, that's the most sucessfully commercialised example. Gotham (GQ magazine) is another big one. It's maybe a bit less common for newspapers/magazines now as print media dies. But almost every [very] large established company has their own fonts, it's just relatively unusual for them to be available commercially (See also v large tech companies commissioning UI fonts)

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Spatulater bro! posted:

In React how bad is it to load all your data into the initial state?

Here's my setup: Within App is a component called Contest which will render once for every instance of a "contest" entry in the database (so it could be many many times). All the contest data gets fetched by App but the Contest components get rendered lazily on scroll. Each contest relies on the user data passed into it from App. The way I see it I have two options for loading the user data: either make an AJAX call from every single Contest to fetch only the user data for that contest, or load all the user data into the initial state of App and pass it down. Or is there a third option?

_If_ you can get away with loading all the data imo do it; it'll make your life a helluva lot easier. And if there are an obscene number of contest records, then can you get the data in paginated blocks (edit, and then do what Clark Nova says)?

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Spatulater bro! posted:

You mean from a performance perspective? That's my main concern. And I'm not sure how to measure the effect the size of the initial state has on load time.

Yea, from a performance perspective. Make a judgement call based on literally how long the request takes for a user with chunky data, and just see whether you're happy with that or not? It depends on how much data there is for each record: if there isn't much then grabbing it all at once maybe won't be too costly. And you could always just make a request for a subset of the data (at the most minimal, just the collection of IDs for each record + I guess some descriptive field). Then that allows you to render UI. Then you can request more detailed individual records when a user selects one of them (obviously this depends on how your app works)

RobertKerans fucked around with this message at 17:14 on Apr 16, 2019

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

gbut posted:

Only if GraphQL or similar API that allows you to define the response scope. If you don't have control over the API output, I'm not sure if you could pull something like that easily with a large set of large records. Chunking would be better in that case.

Ah that is true, my head's been stuck in GQL stuff for the last few months and I kinda forgot it wasn't that easy. Pagination is normally pretty doable. Need to more of an overview of the whole thing though (what counts as a lot of records, how much data is coming through per record, etc)

RobertKerans fucked around with this message at 18:49 on Apr 16, 2019

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.
Wierd thing I can't figure out. I've got some state in a plain TS React app where the relevant Context looks basically like this:

code:
interface Block {
  id: string;
  backgroundColor?: string;
  // some other properties
}

interface WorkspaceState {
  blocks: Record<string, Block>;
  blockIds: string[];
  selectedBlocks: Record<string, null>;
}
I can add blocks; one gets created, id is generated, gets added to the blocks field, id gets added to the blockIds field. I map over the blockIds to render blocks.

I can click to select/deselect blocks, and they get added/deleted from the selectedBlocks field respectively. When they are selected I can do stuff to them like delete them or change the background colour.

What I don't get is that if I change the WorkspaceState to this, which to me is a bit clearer and gives me iterable data structures rather than plain objects:

code:
interface WorkspaceState {
  blocks: Map<string, IBlock>;
  selectedBlocks: Set<string>;
}
And then, for example, (state.selectedBlocks.has(id)) ? do blah instead of (id in state.selected blocks) ? do blah. Or to iterate over them, state.selectedBlocks.forEach instead of Object.keys(state.selectedBlocks).forEach. Or for a rendering loop over all of the blocks, [...state.blocks.keys()].map(... instead of state.blockIds.map(.... etc.

And the app goes from being nippy to super duper slow. Like, everything just stops being usable. It still works, it's just feels like it's going through treacle, and everything is an update or few behind, visually. So for example if I select a block, it doesn't show that until a few more things have been clicked - I can inspect the state and see that it has updated, but React is not reflecting that. I'm just a bit baffled. I remember getting similar issues when I did the same on a Redux-backed app last year, and just thought I'd made some stupid mistake and forgot about it, and then I'm seeing the same behaviour as soon as I switch from using objects (+ arrays of IDs where necessary) to Maps/Sets.

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.
the website is just confusing as gently caress, it's basically just a static site generator right? and I used to use those quite a bit for building little sites for people as a side job, but I avoided Gatsby because the fluff on the site seemed jargon-laden as gently caress. "Gatsby is a static pwaaah generator" "Gatsby is INTERNET SCALE" "Don't build your website with last decade's tech". Like I can install Middleman and build some HTML pages then shove the HTML on a server and I'm done, is Gatsby just a more fragile, complicated version of that? And is it basically the same as Next.js (which seems loads simpler though that's maybe just cos they've got better content writers for their website)?

RobertKerans fucked around with this message at 09:56 on Jul 8, 2019

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.
Rich Harris seems quite straightforward, so maybe the description is slightly tongue-in-cheek? It is pretty meaningless, but I think I'm maybe willing to give the benefit of the doubt because Rollup is good, Svelte seems pretty good from the little I've played around with it, and he wrote a thing recently about how web components are in most cases a bit poo poo which I heartily agreed with. Whereas I'm still to be persuaded on Gatsby (it just seems a bit sprawling for something that feels like it should be v simple, but that may just be the way it's being presented on-site) but I'll have go at it as people here seem to think it is cool & I'm just about to build another small site

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Lumpy posted:

I just can't get over the phrase "surgical updating"

It's ridiculous isn't it, but I think "cybernetically enhanced web apps" tops it

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.
Possibly brilliant, but I've only made the toyiest of toy apps so far. Setup was the quickest & simplest experience I've had for a long time, development feels jQuery-level easy, and developing a few tiny things in it genuinely made me happy. Was all v nice but I need to see how it handles more substantial stuff.

Edit: I kinda felt the same way about Ractive, and made a few widgety things using it (price calculators & stuff) for the company I was working for at the time, and they worked great, but it fell down on more complex stuff. I think that was the point of it tho, to allow The Guardian to easily build little dataviz things they could dump into their site, and Svelte seems to allow for similar self-contained little widgety things. Docs/tutorials/examples are all miles better for Svelte than they ever were for Ractive, ecosystem might be an issue tho

RobertKerans fucked around with this message at 23:40 on Jul 8, 2019

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Social Animal posted:

Has there been some update? I haven't used redux in over a year since I stopped working on an SPA.

react redux works fine with hooks now is the main thing, I've just now gutted every mapState/mapDispatch/connect from the app I'm working on which was nice.

I'd like to strip out redux completely tbh though, I don't feel it's as useful as it was (and I really want rid of sagas), it's getting close to a point where that's viable, but I want suspense for data loading in place so it'll have to be later this year.

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

a hot gujju bhabhi posted:

I will never understand utility first CSS. Surely all you've done is moved inline styles to a different HTML attribute?

Sort of, but it's a. configurable in a single place, b. extremely constrained, as prom candy said. I think I posted that same link a few months ago, as was pretty skeptical at the time, but it makes building stuff ridiculously fast. Also [caveat that this is only 3 months into an experiment] I feel like this is the best way to approach styling React Native, it's been a helluva lot more pleasant to work with than any other approach:

JavaScript code:

export default Stylesheet.create({
  dark: { color: "#foo" },
  light: { color: #bar" },

  bg_dark: { backgroundColor: "#foo" },
  ......
});

// then somewhere else

import s from "./Styles";

export const Fart = (props) => (
  <View style={[s.bg_dark, s.rounded, s.p_sm]}>
    <Text style={[s.light, s.bold]>Fart</Text>
  </View>
);


:shrug:

RobertKerans fucked around with this message at 14:59 on Aug 11, 2019

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Thermopyle posted:

It's been awhile since I selected a routing solution for a react/redux app.

I'm a little disappointed to see that since I last picked react-router for a project a year or so ago that it doesn't seem to have progressed in the keeping-state-in-redux area.

I'm leaning towards react-first-router as a project I'm maintaining now already uses that, but I'm just wondering if anyone has any good patterns for using redux with react-router or thoughts about why we shouldn't be integrating urls and routing more into our redux state.


I am pretty firmly in the camp of separating routing concerns and Redux concerns. For one thing, I don't think there's a solid solution -- I've tried almost everything, and it always ends up being gerryrigged in some way, or something breaks because the deps (generally router, redux and the bridge library between the two) go out of sync api-wise and cause something to go pop. Once I gave up trying and split the two concerns, like most of the docs suggest, everything has been simpler and I'm honestly not sure now why I've always tried so hard to integrate the two things -- they don't _really_ seem to overlap very much.

caveat: I don't like using Redux for anything except data, as I now primarily use it as just a serializable data store I can use to save/rehydrate an app. I don't like any UI stuff like loading/errors/fetching logic etc to be anywhere near Redux so I'm a bit biased, I personally think routing falls under the same banner.

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.
Yep, RR mainly because of that huge community. The various available routing options aren't exactly great anyway, there needs to be a good reason to use anything else. Re the API changes -- Reach Router seemed good, an attempt to fix some of RRs failings, but it's being merged into the next version of React Router, so I guess the shifting API is kinda due to that?

RobertKerans fucked around with this message at 20:09 on Sep 14, 2019

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Queen Victorian posted:

Anyone have an opinion on ImmutableJS? I haven’t had any experience with it before encountering it in the React codebase at my new job, and now that I’ve dealt with it, I don’t think I like it very much at all. Generally, it’s badly implemented in this case, makes things more difficult, and is hindering performance more than helping (toJS() calls everywhere, including inside mapStateToProps). From what I understand, immutability is important for functional programming, but our components are mostly class-based (with some randomly being functional components). No one is sure why it’s even in use (the developer who added it and is otherwise responsible for most of what’s wrong with the codebase is no longer with the company).

Using an immutability library makes it much easier to enforce it in Redux and avoid accidentally breaking things. Immutable is/was the most widely used. And because of Redux' ubiquity you're gonna get a load of devs who install it by default on a React project (whether that be cargo culting or not). Re usage, the serialisation/deserialisation steps are a particular pita. Probably avoid if you can as it'll complicate things

If you do actually need immutability, I'd strongly advise using Immer over anything else -- it uses no new data structures, it's API is tiny (you're only likely to use the single core function it exports as default) and it's stupid simple. Uses proxies so definite perf hit

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.
Ok, so say I have a context in React, and I'm using TypeScript. Issue I've got is. If I type the context like this:

code:
React.createContext<FooStuff>({ ...a_load_of_default_values})
That works, but the issue is that often I don't have default values -- for example, the values may be calculated before being added to context, or there may be a large number of them, or they may be highly context [heh] sensitive. atm I'm writing a small graphing package for the app I'm working on, and I can't have a default graph, it entirely depends on data that isn't there to start off with. Aaanyway, I can't do this:

code:
React.createContext()
Because createContext takes one argument. I could do this:

code:
React.createContext<FooStuff | null>(null)
But that's wrong because then null then goes and poisons the rest of my code (it's never going to be null except for when it's first instantiated). I can do this:

code:
React.createContext<Partial<FooStuff>({})
But that's also wrong, because now I have to put guards in any time I want to access properties held in context in case they're undefined.

And this is static, mainly primitive, read-only properties. When I have functions held in context it generally gets substantially more complicated and annoying.

This is driving me slowly insane, I use context quite a bit and most of the time I use it I spend a half hour or so googling solutions to above issue. Is there a sensible way to do this in TS that I'm just missing here

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.

Aquarium of Lies posted:

Assuming you're using the useContext hook to get to the context later, I wrap the hook to "fix" the TS declaration.

code:
const fooContext = React.createContext<FooStuff | null>(null);
function useFooStuff(): FooStuff {
  return useContext(fooContext)!; // if you haven't seen the ! before, it's a shortcut to tell TS "this isn't null/undefined/"empty""
}

// later on

const fooStuff = useFooStuff() // not null!;

Ahahh, yes I've always got a hook to access the context, and re the !, I have a vague memory of seeing it in the docs but never really looked at it as it's so rarely used. That's spot on though, it'll make things a lot easier going forward, cheers.

RobertKerans fucked around with this message at 23:55 on Jan 7, 2021

Adbot
ADBOT LOVES YOU

RobertKerans
Aug 25, 2006

There is a heppy lend
Fur, fur aw-a-a-ay.
I do like that article a lot, it's basically informed how I've written code using context for the past year or so, but I've found it doesn't actually solve the issue I was having most of the time. Solution (handling it better in the hook) seems stupidly obvious to me in retrospect now, but he doesn't really do that. He's checking if access is literally undefined, which it will be if access is attempted outside of that component tree, but it doesn't really help with typing context. I've been back and forth through this article umpteen times, and despite him saying he fixes typing errors, beyond the specific example I don't see how he does?

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