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 »

Honest Thief: Jan 11, 2009

The whole deal of react is composability, explicitly forbidding children seems wrong because of that. If someone's nesting a bunch of components that will never be rendered is a different case than having a wrong prop.

Honest Thief fucked around with this message at 14:23 on Aug 30, 2020

# ? Aug 30, 2020 14:21

Adbot: ADBOT LOVES YOU

# ? Apr 26, 2024 05:23

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

Everyone making GBS threads on Gatsby and I�m over here using NX, NestJS, and Angular Universal in my new role and unironically having the loving time of my life.

# ? Sep 1, 2020 21:59

Orbis Tertius: Feb 13, 2007

I'm having issues with using typescript interfaces exported from one project in another project. I'm using parcel bundler and yarn link.

So in Project A I have a types.ts file which exports an interface:

code:

export interface RjrProps {
  config: Config;
}

This is imported in and exported from Project A's index.tsx (main module file) like so:

code:

import {RjrProps} from './types.ts'
....
export {
RjrProps,
...other exports
}

In Project B (linked to Project A by yarn link), I import the interface and extend it for the props of a function component:

code:

import {RjrProps} from 'rjr'

interface RjrFormProps extends RjrProps {
data?:any
}

const RjrForm: React.FunctionComponent<RjrFormProps> = (props) => {

...component stuff

}

This code gives me the following error:

code:

 Property 'config' does not exist on type 'IntrinsicAttributes & RjrFormProps'

So, the RjrFormProps interface isn't getting correctly extended by RjrProps. RjrProps is recognized as a valid import in Project B, but not as a typescript interface, it seems.

I'm very new at working with parcel, typescript and also with multiple modules with yarn link, so I'm not sure where to begin looking for the cause of this. Any ideas?

Edit:

I just noticed a probably related error message in vscode for 'rjr' in

code:

import {RjrProps} from 'rjr'

The error:

code:

Could not find a declaration file for module 'rjr'. 'C:/code/rjr2/dist/index.js' implicitly has an 'any' type.
  Try `npm install @types/rjr` if it exists or add a new declaration (.d.ts) file containing `declare module 'rjr';

I tried creating a d.ts file in Project B with 'declare module 'rjr' and now vscode's showing this error for RjrProps:

code:

(alias) module "rjr"
import RjrProps
Cannot use namespace 'RjrProps' as a type.

Even more confused now. RjrProps isn't a namespace...

Orbis Tertius fucked around with this message at 22:57 on Sep 1, 2020

# ? Sep 1, 2020 22:30

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

K I need Vue Router assistance. I don't think I understand how the route matching works.

I have this route:

code:

/forum/{id}/thread/{threadId}

And it works. Problem is: I am trying to add the following route:

code:

/forum/{id}/thread/{threadId}/reply

And when I try to navigate to it - console errors saying "Avoided redundant navigation to current location". But I don't understand why it seems to stop trying to match as it hits the first route, which is why I assume it's saying redundant.

Here is the working parent route, and it's apparently non-working child:

code:

        {
        path: 'thread/:threadId',
        component: ViewThread,
        meta: {
          breadcrumb: { name: 'viewThread' },
        },
        children: [
          {
            path: 'reply',
            component: ViewReplyThread,
            meta: {
              breadcrumb: { name: 'viewReplyThread' },
            },
          },
        ]
      },

Anyone?

# ? Sep 2, 2020 02:52

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

HaB posted:

K I need Vue Router assistance. I don't think I understand how the route matching works.

So right as I was turning in last night, I had an idea. Got up this morning and tried it and it work, but I'm still not sure I understand why. What worked was this:

code:

      {
        path: 'thread/:threadId',
        component: {
          render(c) {
            return c('router-view');
          },
        },
        meta: {
          breadcrumb: { name: 'viewThread' },
        },
        children: [
          {
            path: '',
            component: ViewThread,
            meta: {
              breadcrumb: { name: 'viewOneThread' },
            },
          },
          {
            path: 'reply',
            component: ViewReplyThread,
            meta: {
              breadcrumb: { name: 'viewReplyThread' },
            },
          },
        ]
      },

Or basically: parent route just renders a router-view. First child has empty path and renders the original parent component. Child has 'reply' path and renders the reply component.

So that feels very counter-intuitive to me. I am assuming it's because both "child" routes (quotes because the empty path one doesn't seem like a child, per se), need a router-view to render into?

# ? Sep 2, 2020 11:52

uncle blog: Nov 18, 2012

So, I have another issue with TypeScript and linting. This time with some added Apollo to spice it up:

Trying to type some methods that use Apollo hooks.

code:

  getGoals: () => (boolean | ApolloError | { contexts: Goal[ ] })[];

Calling the function looks like this:

code:

const [loading, error, data] = getGoals();

  useEffect(() => {
    if (data && data.contexts) {
      setOrderedContexts([...data.contexts]);
    }
  }, [data]);

This gives me the following error:

code:

Property 'contexts' does not exist on type 'true | ApolloError | { contexts: Goal[]; }'.

So I don't really know what to do here. Life was a lot easier with "any" plastered everywhere.

# ? Sep 3, 2020 11:42

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

uncle blog posted:

So, I have another issue with TypeScript and linting. This time with some added Apollo to spice it up:

Trying to type some methods that use Apollo hooks.
code:
  getGoals: () => (boolean | ApolloError | { contexts: Goal[ ] })[];
Calling the function looks like this:
code:
const [loading, error, data] = getGoals();

  useEffect(() => {
    if (data && data.contexts) {
      setOrderedContexts([...data.contexts]);
    }
  }, [data]);
This gives me the following error:
code:
Property 'contexts' does not exist on type 'true | ApolloError | { contexts: Goal[]; }'.
So I don't really know what to do here. Life was a lot easier with "any" plastered everywhere.

Without seeing your getGoals code it's hard to say. If that is just a wrapper around useQuery, then the typing may be wrong. Also, as a general rule, I find implicit types are your friend. Unless there is a good reason to, let the compiler figure it out if it can and stay out of the way. Add types when needed, not "just because".

EDIT: The type for the data param of a useQuery is data.queryName.whatever so if your query name isn't "contexts" then that is probably the issue, but again, without seeing the actual code it is hard to say.

Lumpy fucked around with this message at 13:37 on Sep 3, 2020

# ? Sep 3, 2020 13:33

Macichne Leainig: Jul 26, 2012; by VG

The loading bool is supposedly true. Maybe the data property is truthy and still passing your check for that, but has no contexts property still?

Shot in the dark though, the type definition looks fine to me.

# ? Sep 3, 2020 13:39

uncle blog: Nov 18, 2012

Lumpy posted:

Without seeing your getGoals code it's hard to say. If that is just a wrapper around useQuery, then the typing may be wrong. Also, as a general rule, I find implicit types are your friend. Unless there is a good reason to, let the compiler figure it out if it can and stay out of the way. Add types when needed, not "just because".

EDIT: The type for the data param of a useQuery is data.queryName.whatever so if your query name isn't "contexts" then that is probably the issue, but again, without seeing the actual code it is hard to say.

As you suspected, it's basically just the useQuery function.

code:

const GET_CONTEXTS = gql`
  query Contexts {
    contexts {
      id
      Name
      Description
      seq
      Functions {
        id
        Description
      }
    }
  }
`;

const getGoals = () => {
    const { loading, error, data } = useQuery(GET_CONTEXTS);
    return [loading, error, data];
  };

I tried reformatting it to include the query name, but without much help.

code:

getGoals: () => (
    | boolean
    | ApolloError
    | { Contexts: { contexts: Goal[] } }
  )[];

This is the new error message:

code:

TypeScript error: src/pages/contexts/contexts.component.tsx(69,22): Error TS2339: Property 'contexts' does not exist on type 'true | ApolloError | { Contexts: { contexts: Goal[]; }; }'.
 Property 'contexts' does not exist on type 'true'.

So it also seems to think the returned data object is of type true?

# ? Sep 3, 2020 15:27

uncle blog: Nov 18, 2012

Protocol7 posted:

The loading bool is supposedly true. Maybe the data property is truthy and still passing your check for that, but has no contexts property still?

Shot in the dark though, the type definition looks fine to me.

It won't have the contexts property until the data is actually loaded. Tried adding undefined and null to the type definition with no luck.

# ? Sep 3, 2020 15:30

Macichne Leainig: Jul 26, 2012; by VG

uncle blog posted:

It won't have the contexts property until the data is actually loaded. Tried adding undefined and null to the type definition with no luck.

Well I know that, but your error message says:

quote:

Property 'contexts' does not exist on type 'true | ApolloError | { contexts: Goal[]; }'.

I'm a little suspicious that it is saying "true" there, which should represent the loading boolean, right? If the loading bool is true, then I'd expect the data object to not have data yet. I don't use Apollo so I don't know how exactly the hook works, but maybe you could do something like:

code:

useEffect(() => {
	if (data && 'contexts' in data) {
	  setOrderedContexts([...data.contexts]);
	}
}, [data]);

Macichne Leainig fucked around with this message at 15:41 on Sep 3, 2020

# ? Sep 3, 2020 15:38

Aquarium of Lies: Feb 5, 2005; sad cutie

she/her; Taco Defender

I'm assuming getGoals returns a three-element tuple? Try this:

code:

getGoals: () => [boolean, ApolloError, { contexts: Goal[ ] }];

With your types, you're returning a list where each element in the list can be one of boolean, ApolloError, or { contexts: Goal[ ] }. So in your usage TypeScript sees the following:

code:

const [loading, error, data] = getGoals();
// type of data is either boolean, ApolloError, or { contexts: Goals[] }. TS can't tell which.

useEffect(() => {
  if (data && data.contexts) { // If data is boolean or ApolloError, those don't have contexts. Remember, TS can't tell which it actually is!
    setOrderedContexts([...data.contexts]);
  }
}, [data]);

The types I give for getGoals specifically state it's a three-element tuple where the third element is of type { contexts: Goal[ ] }.

E: The reason the error says Property 'contexts' does not exist on type 'true | ApolloError | { contexts: Goal[]; }'. is because TS is smart enough to figure out that data can't be false - it narrows the type from boolean | ApolloError | { contexts: Goal[ ] } because you check for the truthiness of data before using data.contexts.

Aquarium of Lies fucked around with this message at 19:31 on Sep 3, 2020

# ? Sep 3, 2020 16:00

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

Can I ask why you're wrapping useQuery like that? Also I'm on my phone so maybe reading this wrong but I think if you have a function that wraps a hook that function is pretty much a defacto hook as well. Typescript won't care but the convention would be to call it useGetGoals

# ? Sep 3, 2020 17:15

uncle blog: Nov 18, 2012

Thanks all!

A modified version of Aquarium of Lies' suggestion (with the addition of a possible undefined for the middle one) did the trick:

code:

getGoals: () => [boolean, ApolloError | undefined, { contexts: Goal[ ] }];

prom candy posted:

Can I ask why you're wrapping useQuery like that? Also I'm on my phone so maybe reading this wrong but I think if you have a function that wraps a hook that function is pretty much a defacto hook as well. Typescript won't care but the convention would be to call it useGetGoals

I put all the functionality that access the db in a global context file, to make the presentation layer more agnostic. (Apollo seemingly wants to put its querys and mutations right in the jsx, which seems very wrong to me, but I'm pretty new at this.) As far as I remember, I wanted the option to do some remapping or other form of formatting of the data before giving it to the presentation layer. This didn't end up happening, but for I vaguely remember it being easier to send a tuple than the raw destructured stuff Apollo returns. I'd be happy to know if I could achieve a similar sort of decoupling with a better method, again, as I am still a pretty fresh developer.

vvv:
This is great! I'll probably do just that.

uncle blog fucked around with this message at 09:51 on Sep 4, 2020

# ? Sep 3, 2020 19:09

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

That's fair, most people don't tend to separate their data layer and presentation layer quite like that in React but if you have a reason for doing it there's nothing wrong with it. Technically though getGoals is a custom hook so if you want to make that clear to any other dev working on this it should be named useGetGoals (otherwise it won't be obvious that it plays by the rules of hooks: must be called in a component, can't be called conditionally, can't be called inside the body of another function, etc.)

Personally I would probably just send back the result of useQuery rather than destructuring it and putting it in a tuple, but that's just me. If it's an object then you can do:

const { data, loading, error } = useGetGoals();

or

const { error, loading, data } = useGetGoals();

but if it's a tuple you have to remember the order and if you ever want data but not loading or error it's more of a pain. Plus what happens when you realize you also wanted networkStatus and fetchMore from useQuery?

Also if you just return the result of useQuery you'll get a bunch of implicit typings for free:

code:

function useGetGoals() {
  const queryResult = useQuery<{ contexts: Goal[] }>(GET_CONTEXTS);
  let data = queryResult.data;
  if (data) {
   data = doSomeOperationsOnData(data);
  }
  return { ...queryResult, data }
}

Typescript will be able to infer pretty much all the typings in here for you (notice I pass the shape of the query result into useQuery)

# ? Sep 3, 2020 20:04

Macichne Leainig: Jul 26, 2012; by VG

Anyone have tips for debugging PWAs?

I've got a little app that's used by people out in the field to take pictures of things like utility poles, meters, etc.

I've turned it into a PWA so people can work offline.

I have the basics cached by the SW: The app bundle, supporting css/js libraries, and since it uses a map, it caches whatever tiles it can.

All this works great when you pop open the app on an offline Android device; it's able to load the app, and the first few API calls are cached so it can load all the initial app data with no problems.

However, on iOS it looks like this:

The little spinner should be in the top left and saying something like "Loading data, please wait" and the map is clearly all messed up.

So clearly something is erroring out on the iOS side of things. However, trying to use the remotedebug-ios-webkit-adapter is a pain in the rear end in whether or not the phone will show up in Chrome, and plugging the phone into a bonafide Mac only lets you debug the app and SW on Safari proper, not the version you add to your home screen that works offline.

I'd really love to make use of the remotedebug-ios-webkit-adapter since I can use it to debug the "app" version of the PWA, but it feels like sorcery getting my phone to show up in Chrome's remote devices section.

Thankfully the guys who use the app have mostly Samsung phones so it's not a big problem, but I'd like the basics of the app to function offline consistently on both mobile platforms before working on other offline features.

Frustratingly, it seems to work fine if you start the app online, and then go into airplane mode. So that's a big :shrug:

for me as well. It's only on a fresh, completely offline launch that fails, and I can see all the network requests getting loaded in from the Service Worker on the Android and Chrome versions just fine.

Macichne Leainig fucked around with this message at 17:31 on Sep 4, 2020

# ? Sep 4, 2020 17:28

marumaru: May 20, 2013

last i checked (granted it was a while ago) mixing PWA and iOS was a recipe for disaster. i thought it had improved since then, but i guess not

# ? Sep 4, 2020 17:48

Macichne Leainig: Jul 26, 2012; by VG

For what its worth, I discovered a tool called Eruda that gives me dev tools on mobile, and it works in the PWA as well. So that's at least one decently large step closer to being able to get my debug information. Just enabled it for my user account only, and I think I figured out at least why the map is funky, I missed caching the CSS for Leaflet in the SW.

Edit: Wow, and not being able to load the CSS for the Leaflet map was causing all the issues on iOS period, but at least it's working now!

Macichne Leainig fucked around with this message at 18:28 on Sep 4, 2020

# ? Sep 4, 2020 18:21

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

Inacio posted:

last i checked (granted it was a while ago) mixing PWA and iOS was a recipe for disaster. i thought it had improved since then, but i guess not

I dunno I was doing PWAs for iOS in 2012 without any issues (other than appcache :argh:

)

# ? Sep 5, 2020 02:18

putin is a cunt: Apr 5, 2007; BOY DO I SURE ENJOY TRASH. THERE'S NOTHING MORE I LOVE THAN TO SIT DOWN IN FRONT OF THE BIG SCREEN AND EAT A BIIIIG STEAMY BOWL OF SHIT. WARNER BROS CAN COME OVER TO MY HOUSE AND ASSFUCK MY MOM WHILE I WATCH AND I WOULD CERTIFY IT FRESH, NO QUESTION

Super open-ended question, but just wondering what kind of solutions people have experience with for managing back and forth communication with a server, WebSocket stuff. There's obviously loads of different libraries and techs for this these days, just curious what kind of platforms, libraries, etc people like to use for this problem. I'm working on a stupid pet project game to help build my Vue skills and have a need now to develop some server-side logic and I want the server to be able to push information to the client (when a mob spawns, when a new player joins, etc). Just want to get a good idea of what's out there and what people have enjoyed using so I can pick something to learn.

# ? Sep 5, 2020 09:36

Vesi: Jan 12, 2005; pikachu looking at?

a hot gujju bhabhi posted:

Super open-ended question, but just wondering what kind of solutions people have experience with for managing back and forth communication with a server, WebSocket stuff. There's obviously loads of different libraries and techs for this these days, just curious what kind of platforms, libraries, etc people like to use for this problem. I'm working on a stupid pet project game to help build my Vue skills and have a need now to develop some server-side logic and I want the server to be able to push information to the client (when a mob spawns, when a new player joins, etc). Just want to get a good idea of what's out there and what people have enjoyed using so I can pick something to learn.

I'm running https://github.com/nhooyr/websocket the examples are simple and production grade

for testing it out https://github.com/hashrocket/ws

Vesi fucked around with this message at 10:33 on Sep 5, 2020

# ? Sep 5, 2020 10:31

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

https://epicreact.dev/why-i-love-react/

This is was how I wish I could tell people why I like React.

# ? Sep 10, 2020 14:37

Macichne Leainig: Jul 26, 2012; by VG

Just really want to confirm if this is sane. Still working on the offline-capable map web app.

Basically, a user can have anywhere from a few hundred to a hundred thousand items on a map visible to them. Since this needs to work offline, I have the following set up:

- A service worker, caching the production React app bundle, as well as a Network First strategy for caching backend API calls.
- An IndexedDB with all of the user's visible records, so that the full record detail is available locally as well.

Does this sound legitimate for an offline-capable web app strategy?

So basically the SW is free "offline mode" caching, and the React app itself is aware of the IndexedDB and will pull from that if the app is offline.

This is all new technology to me, so I really just want to know if it sounds like I'm doing anything egregiously wrong before I start adding more offline capability (basically, we just want the ability to keep track of changes offline and prompt the user to synchronize changes when back online.)

# ? Sep 10, 2020 17:23

Anony Mouse: Jan 30, 2005; A name means nothing on the battlefield. After a week, no one has a name.; Lipstick Apathy

Lumpy posted:

https://epicreact.dev/why-i-love-react/

This is was how I wish I could tell people why I like React.

This is good. "React is simple" is the #1 thing for me.

Trying to learn Angular: painful slog through a 3 hour online course, learning about "directives" and "data binding" and other confusing un-JavaScript concepts, all to make the simplest of simple TODO apps. Why the gently caress am I doing this?

Trying to learn React: oh, I just put my data in a variable, have my function return some "HTML" and plug the value directly in where needed? So damned simple and compatible with my existing JavaScript knowledge.

# ? Sep 11, 2020 21:54

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

i like react too but i�m glad my job uses vue. i feel like i have a better understanding of what works and what doesn�t. vue makes some things a lot simpler, but also is missing crucial things that the react team thought about a long time ago

# ? Sep 11, 2020 22:35

Vincent Valentine: Feb 28, 2006; Murdertime

I like React because literally everyone uses it and so every problem you could possibly have with it has a well-received Stack Overflow post, a blog post from Dan Abramov, a 30-minute youtube video by a polite Indian fellow explaining it in detail, and then a plugin that just straight-up solves your problem for you if you don't want to read any of those.

# ? Sep 12, 2020 12:16

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

Grump posted:

i like react too but i�m glad my job uses vue. i feel like i have a better understanding of what works and what doesn�t. vue makes some things a lot simpler, but also is missing crucial things that the react team thought about a long time ago

Can you elaborate on this? Vue is my daily driver now as well, and tho I worked with both ng and ng2, I can definitely understand why people don't like them. But I'm curious as to what you think Vue is missing.

My responses to common arguments over the 2 are as follows:

"React is simple"

is it? Compared to ng2 at least - you are comparing a V (React) to an MVC stack. So I would suggest that by the time you are into React, Redux, axios/fetch and all the other stuff you actually need to have a "complete" React app - it's about as complex as anything else.

"I don't want logic in my templates!"

Well, I don't want templates in my code. React to me is super obtuse and hard to write and read. JSX is my personal worst-case scenario of a programming language. Would much rather stick some extra attributes on elements that say show this or not than write....what JSX is.

To me Vue is basically the perfect happy medium, and seems to have learned from the mistakes of Angular and React to come up with something that really is simple. By the time you add decorators and class components, it's nice and clean and easy to work in. Plus, you can even write JSX if you want to for Vue.

# ? Sep 12, 2020 12:48

Ola: Jul 19, 2004

How many of you who love React have tried Elm?

# ? Sep 12, 2020 12:49

gbut: Mar 28, 2008; 😤I put the UN🇺🇳 in 🎊FUN🎉

That's not fair.

Did, and love it, but will never get my team onboard. Which is sad.

# ? Sep 12, 2020 13:10

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

Ola posted:

How many of you who love React have tried Elm?

Heard great things but I learned to go where the money's at

# ? Sep 12, 2020 14:48

Macichne Leainig: Jul 26, 2012; by VG

I have not tried Elm but it looks cool.

Learning a new language is a hard sell for me when I feel like modern JS really isn�t that bad, especially paired up with typescript.

Though I also know when React is extremely painful; when your offshore team builds an app in a 3500-line mega-component, for example.

Thankfully I�ve refactored it significantly and we�re only down to 2200 now! :suicide:

# ? Sep 12, 2020 14:49

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

I would fire that team. Into the sun.

# ? Sep 12, 2020 15:02

Macichne Leainig: Jul 26, 2012; by VG

prom candy posted:

I would fire that team. Into the sun.

I have tried. At the very least I�m the only one working on the app now.

One of them says he�s a front-end guy, and I told my boss �if he�s a front end guy, then I�m a handyman for installing my own blinds with a drill and 6 screws.�

Wondering if a complete rewrite would have been easier at this point.

Macichne Leainig fucked around with this message at 15:15 on Sep 12, 2020

# ? Sep 12, 2020 15:12

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

HaB posted:

Can you elaborate on this?

The first thing that comes to mind is shouldComponentUpdate and the React.memo callback.

With Vue, you kinda just have to trust that it's not going to re-render when it's not supposed to, and when you're getting too many re-renders, it's harder to debug and you have to bend over backwards a little bit. I'm not saying it's impossible to prevent too many re-renders, but requires more thinking and refactoring for sure.

TypeScript support is bad (and yes I know that's changing in Vue3).

You can't use imported utility functions in the markup because templates only have access to this. Also, babel plugins like optional chaining have no support in the template.

If I had more time to think, I could name a few more, but on the flip side:

Vuex and Vue Router are miles easier than the React counterpart. Scoped css is good (when you don't have people on your team writing lovely CSS). The dev onboarding experience is way faster too.

# ? Sep 12, 2020 16:28

Ola: Jul 19, 2004

Protocol7 posted:

I have not tried Elm but it looks cool.

Learning a new language is a hard sell for me when I feel like modern JS really isn�t that bad, especially paired up with typescript.

Though I also know when React is extremely painful; when your offshore team builds an app in a 3500-line mega-component, for example.

Thankfully I�ve refactored it significantly and we�re only down to 2200 now!

We have 2000+ lines in Main.elm in our web app and I would have no qualms about adding 2000 more. God knows how many more lines across all the sub pages, types etc. The payload is starting to get a bit heavy, but performance is still excellent. Refactoring is so easy as well, you can just rip a bunch of stuff out and the compiler tells you what you need to fix.

With React you've tipped your toes in functional already, learning the syntax is a piece of cake. Oh god I've become a language evangelist.

# ? Sep 12, 2020 16:41

Macichne Leainig: Jul 26, 2012; by VG

Ola posted:

We have 2000+ lines in Main.elm in our web app and I would have no qualms about adding 2000 more. God knows how many more lines across all the sub pages, types etc.

At least you had subpages and types. Literally everything for this app was in App.js. No React component imports to be seen.

# ? Sep 12, 2020 16:50

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

Protocol7 posted:

Just really want to confirm if this is sane. Still working on the offline-capable map web app.

Basically, a user can have anywhere from a few hundred to a hundred thousand items on a map visible to them. Since this needs to work offline, I have the following set up:

- A service worker, caching the production React app bundle, as well as a Network First strategy for caching backend API calls.
- An IndexedDB with all of the user's visible records, so that the full record detail is available locally as well.

Does this sound legitimate for an offline-capable web app strategy?

So basically the SW is free "offline mode" caching, and the React app itself is aware of the IndexedDB and will pull from that if the app is offline.

This is all new technology to me, so I really just want to know if it sounds like I'm doing anything egregiously wrong before I start adding more offline capability (basically, we just want the ability to keep track of changes offline and prompt the user to synchronize changes when back online.)

As someone who worked for a while on data-heavy offline capable web apps, it sounds like you�re doing things right to me.

As I�m sure you�re aware the synchronization is the most complicated part of what you�re trying to do and my work never really had to address it thankfully. Look up CRDT for a good approach to resolving sync conflicts.

# ? Sep 13, 2020 15:23

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

Ola posted:

How many of you who love React have tried Elm?

I like Elm a lot, and do many personal projects in it. Work is lots of data visualization, graphQL, and Auth0 and so on, so the 3rd party ecosystem is a big factor in what drives our choices. Elm is cool and good though.

# ? Sep 13, 2020 17:19

Macichne Leainig: Jul 26, 2012; by VG

Chenghiz posted:

As someone who worked for a while on data-heavy offline capable web apps, it sounds like you�re doing things right to me.

As I�m sure you�re aware the synchronization is the most complicated part of what you�re trying to do and my work never really had to address it thankfully. Look up CRDT for a good approach to resolving sync conflicts.

Thankfully there is a very important assumption we can use to our benefit for syncing offline changes; people won't be working in the same record at the same time. The workflow is that the records get assigned to field workers, then the field workers go out and do whatever is necessary at that location based on the status of the record.

So, since a record can't be assigned to two field workers at the same time, we can basically only capture changes to rows that are assigned to them, and then it's just as simple as waiting until we are in a known good network area to actually make the changes.

Protip to anyone working with indexed DB though... don't insert 150k records at once, batch them into a few different transactions. Inserting 150k records into an Indexed DB in one transaction crashes iOS Safari.

# ? Sep 13, 2020 18:27

Adbot: ADBOT LOVES YOU

# ? Apr 26, 2024 05:23

smackfu: Jun 7, 2004

Ran into some code at work recently where I guess someone had just learned about React lazy loading so they made ever single component usage lazy loaded. It worked but whyyyyy.

# ? Sep 14, 2020 13:33

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

«‹›234 »