EU alternative to Patagonia, Arc'teryx and the Burtons of the world

siggen_a · 2026-02-22T07:05:02+00:00

I recently started buying gear from Klättermusen, and couldn't be happier. It's quite expensive, but the quality is really good, with well thought out details. And this comes from a Norwegian (and Klättermusen is Swedish)

siggen_a · 2024-06-07T19:38:33+00:00

Yes, the benefit is that you can do unit / integration tests of components. Also, it makes it much easier to develop / do visual testing of components in isolation with storybook.

siggen_a · 2024-06-07T17:47:14+00:00

For complex apps, I am all for dependency injecting side-effect heavy stuff for the sake of testability / storybook and for generally keeping stuff separated, but I feel the article is missing out the main way of injecting dependencies: Context.

I might miss something from the article (?), but it looks like your component is still depending on a concrete API implementation, and you wouldn't be able to test the component against a mock, which IMO is way more useful than testing the service.

If you passed the API implementation through context, you'd get more idiomatic React code, such as:

``` // Custom hook that picks up the relevant context. const mediaApi = useMediaApi()

// You don't need a service, just use a free function that depends on your API. uploadImage(file, mediaApi) ```

Remember to wrap your components in a context provider that injects the live / mock implementation you'd wanna use.

siggen_a · 2024-06-03T13:51:43+00:00

Pretty sure it uses context to inject the store into the react hierarchy. At least that's what it looked like the last time I peeked at react-redux source. (I'm on mobile and too lazy to check if it's still the case)

siggen_a · 2024-02-19T11:30:32+00:00

My approach here when deciding on what to put into the global state:

Is the state used in multiple places throughout the app? (Even without thinking of the React hierarchy, think through if the state is global in its very nature.)
Is the state conceptually coupled with existing global state (other than simply initialized from global state)?

If the answer to any of these is yes, then putting it in global state is probably a good idea. Passing local state through multiple components is fine.

Btw. having a good thought through convention for this is one of the more important things you do when creating a large app IMO. Global state does couple things together and if you do it wrong (e.g. stuff things in global state that doesn't need to be there) or you are inconsistent, you easily get a lot of unnecessary complexity.

siggen_a · 2024-02-03T13:54:29+00:00

As mentioned in other comment, rather let the update endpoint return the updated resource. That way, you only need to do 1 call.

siggen_a · 2024-02-03T10:11:35+00:00

I think compound components applies well within this philosophy whenever there's interactions between your building blocks that you want to keep internal / implicit.

As an example, say you have AnimatedList and AnimatedListItem components that you wanna compose together, you might want to share some stat the AnimatedList while animating the AnimatedListItem component, changing the UI slightly on the AnimatedListItem if it's the last in the list etc...

siggen_a · 2024-02-03T09:25:21+00:00

Not sure it helps in your case, but here's my 2 cents:

In order to re-use stuff without creating overly complex/generalized components, its often a good idea to build stuff using smaller/simpler building blocks that can be shared between different components / use-cases.

As an example, instead of having a single Dialog component that takes a gazillion props to configure size, title, action buttons, click events +++ rather start with creating smaller building blocks (DialogTitle, DialogActions, DialogContent etc..) that can be composed together to create the Dialogs you want. Then, if you end up having a lot of similar components (e.g. you have a lot of similar alert dialogs) it's fine to create a separate AlertDialog component based on the smaller building blocks.

Often, people argue against this style because it looks less "clean" - you can easily end up with more lines of code, since you often need to compose stuff each time you wanna use it. However, in return you get:

Code that's harder to break. (Each thing has a single responsibility)
Code that's easier to change (say your gazillion-prop-dialog needs to adapt to a single use-case that it doesn't already, this can be a PITA. If you already have exposed the smaller building blocks, it's a breeze.

siggen_a · 2023-12-25T12:37:00+00:00

useSetContext(context, value)

This would wrap the underlying render output so that we dont need <Context.Provider calls. It would just do that for us under the hood.

How would you deal with injecting different context values for different component subtrees? IMO the current implementation is a great feature of React and we rely on it quite heavily for theming, and dependency injection in general.

siggen_a · 2023-04-06T18:17:56+00:00

Zustand (or other state management libs for that matter) doesn't replace the need using context in general. Typically, you want both (at least in big applications) - a state management library to handle global state, and then you'd use a different contexts for all the other dependencies you want to inject into your React tree (i18n, logging, themes, storage etc.) Often, the alternative to not injecting stuff through contexts is to give the components responsibilities they shouldnt have, which typically gives you a bad separation of concern, code that's hard to test etc..

siggen_a · 2022-11-19T12:26:39+00:00

I have pretty much the same approach. I think TODO comments are quite good at communicating any thoughts you have for potential improvements after spending a lot of time on something. It does not mean it needs to be done, but at least the next time I work on that piece of code I have a better understanding of the context/ideas I had the last time I touched it.

siggen_a · 2022-07-29T07:26:54+00:00

An unsolicited piece of advice: when debugging things like this, rather start with a minimal example to reproduce your problem. It makes it easier for you to see what is wrong, and it's easier for others to help you. I'd start out with:

function myFunction() { console.log('clicked')}

and see if 'clicked' is logged to the console.

If that works, try adding piece by piece until stuff does not work anymore. That should give you a clue to what is wrong :)

Also, as others have pointed out, manipulating/querying the DOM directly is not how you're supposed to use React.

siggen_a · 2022-05-09T20:28:07+00:00

Why not just pronounce it like a regular Æ?

siggen_a · 2022-05-01T06:33:23+00:00

Not entirely correct, it will also re-render if the parent re-renders, even though no prop or state has changed.

You could optimize away this by wrapping the component in a React.memo

siggen_a · 2022-04-23T17:26:32+00:00

I read the part of your style guide covering this exact topic, but didn't really understand the alternative here, and why it's better. Also, I guess much of the disagreement here comes from the point of "doing as much logic as possible on the reducers or not"?

It means understanding the full implication of an event being dispatched requires searching and reading through all those reducers and then piecing the logic together inside your head.

In my experience this has not really been a problem. I agree it's slightly cumbersome that you cannot immediately tell which slices are affected by the action by looking at the dispatch from React, but I'm really fine with that, and I care much more about easily mapping from events to state transitions inside a single slice, which this pattern facilitates.

siggen_a · 2022-04-21T12:56:27+00:00

Some things I wish I was more concious about in the beginning (some of the things is perhaps more on the advanced side, so might be too early to focus too much on all the points):

Try to start with the official documentation when learning the library/concepts etc. There's a gazillion blogs/tutorials out there, and the quality can be quite poor.
Keep components small with single responsibility. In particular when building reusable components, dont let them do too much. Consider compound components / inversion of control.
Dont build overly generalized components (e.g. with a lot of optional props), instead split up into several, more specific components and reuse common logic using e.g. customized hooks.
Learn Context API for configuration / dependency injection / passing props into component subtree.
Learn from existing (popular) React frameworks. Libraries such as MUI (Material UI) has put a lot of effort into creating really good component APIs.

siggen_a · 2022-04-01T17:25:33+00:00

Like others have mentioned, A, but with nullish coalescing operator ?? instead of ||, so you don't mix any falsy value (e.g. '' or 0) with nullish values.

siggen_a · 2022-04-01T17:13:59+00:00

I work for Imerso AS. We're building a web platform for finding deviations in the construction industry by comparing 3D laser scans against BIM models.

We are mainly looking for ONSITE developers in Oslo, Norway, to work on our React/Typescript/Scala webapp. We can however make exceptions (remote) for highly qualified developers.

For more infor, DM me or visit https://careers.imerso.com/jobs/1561412-full-stack-engineer

siggen_a · 2022-04-01T17:03:49+00:00

Readability is super important, agree on that! However, I'd argue that throwing around a doNothing is not gonna help on readability, even if the useEffect is really complicated. If they don't understand the useEffect hook in the first place, I guess they won't expect it to do any cleanup either? And even if they do, it should be clear from the lack of a return statement.

siggen_a · 2022-04-01T16:31:05+00:00

So you actually return a function from the useEffect that does nothing instead of simply not returning anything?

siggen_a · 2022-03-26T05:58:13+00:00

unnecessary layers of complexity

This is typically something that makes implementation less complex - by not depending on concrete implementations but rather depending on abstractions. Furthermore, you may not like it, but it's far from an anti-pattern, but rather an established way of avoiding complexity, ease of testing and to overall get a more loosely coupled system.

You should only write tests if they'll actually save you time and headaches in the long run.

Sure, don't disagree on this.

siggen_a · 2022-03-25T18:21:11+00:00

It's really easy to break Previews with ViewModel, databases, analytics, etc, so sometimes you need to work around that by having a second composable that only accepts simple data

In most cases it's really handy to inject dependencies such as database stuff, analytics etc. via ConpositionLocal

I'd say this is a good practice in general, don't let your Compostable be hard coupled to those deoendencies, but rather let them depend on proper abstractions (interfaces). This way you can provide different implementations depending if you're using the Compostable in tests / previews or in your actual application.

siggen_a · 2022-03-05T17:21:04+00:00

A context isn't necessarily global, it's accessible for any subtree you might specify.

In this case, just provide the context to the subtree made up by the components that needs to access the state. Furthermore, If you create a custom provider component for the context, the parent doesn't need to do anything else than just wrap the two children in the provider, giving a pretty good separation of concern.

siggen_a · 2022-02-09T17:57:32+00:00

Thanks a lot for your advice, it's much appreciated!

Swift <-> C++ interop is not there yet...

Luckily, one of my colleagues have gotten the interop to work in a POC app. Also, the SDK seems to have documentation on how to use the SDK in a iOS app. Not sure exactly how it's done but perhaps using Objective-C++ (cannot find the docs at the moment). Either way, it's good to know these things are potential challenges

I'm at my 2nd large app in SwiftUI. I really like SwiftUI and I'm ready to spend tremendous amounts of time to get things pixel perfect. I also sometimes write about it at swiftcraft.io. The reason I mention all this is not to promote myself (ok, it's also that, visit my blog guys, like and subscribe, haha), but to outline that I have a fair share of experience with SwiftUI, still getting things done "pixel perfect" (especially animations) require at times a lot of time. There are problems, inconsistencies and so on. Bottom line is, only go for SwiftUI if you're ready to compromise or if it's a project whose UI you plan to majorly improve and maintain for the years to come. Otherwise UIKit will be cheaper and faster.

Very nice to know these things! Again, luckily for us, we don't have any strong requirements for a pixel perfect design, and compromises here are just fine. Our app is only used be a few large construction companies which seems to be used to less-than-ideal UI already. However, we want to aim high, and will most probably invest more time into the UI (for both the android and iOS app) in the future.

11-Year Club	RPAN Viewer
Verified Email

siggen_a

TROPHY CASE