jamesisaac

You might find this recent blog post from the React Native team informative, about their long-term vision for multi-platform support: https://reactnative.dev/blog/2021/08/26/many-platform-vision

From personal experience, I've had great success targeting the 3 platforms you mention in a single RN codebase, with a very high degree of code re-use.

This isn't really accurate. Presuming you're using react-native-web [1] (the most popular version of RN targeting the web, although there are others), it's essentially just a set of components and APIs, fulfilling RN's API, which sit on top of React DOM.

So anything you could do in React, you can also do in RNWeb, as it's a superset of React.

Of course, you'd need to use the RN components if you want to share code between web and native mobile. But there's nothing stopping you reaching a high degree of code re-use, and/or using React components for the web-only portion of a RNWeb project.

[1] https://github.com/necolas/react-native-web

SEEKING WORK | Remote (London, UK) | Full-Stack Web & Mobile App, Design & Development

Portfolio: https://www.m10c.com/portfolio

Email: james@m10c.com

I've been designing and building apps and web platforms for the last 10+ years, currently freelancing with a small team. Lots of experience helping startups launch future-proof MVPs, and happy to offer any level of assistance across the whole product spectrum (from UX, to marketing, to business strategy..).

Frontend focus is React/React Native, as it's allowed us to target all 3 platforms (web, iOS, Android) with unprecedented efficiency.

Ah I see. That can be achieved since Flow 0.51 with opaque types[1][2]. It seems like TypeScript hasn't yet caught up with this functionality[3].

[1] https://medium.com/flow-type/hiding-implementation-details-w...

[2] https://flow.org/en/docs/types/opaque-types/

[3] https://github.com/Microsoft/TypeScript/issues/15807#issueco...

Yeah I realise you'd never reach the same level of soundness due to the limitations of the underlying JS (although presumably you could get close with a subset?). But that's why it's an interesting challenge, and I think what Flow has shown is that it's possible to get a lot closer than had previously been imagined.

If everyone just accepted the argument 4 years ago that "JS will never be sound" then maybe today TS would still just be Java style `interface` annotations for classes. It's not like the Flow team has reached a ceiling at this point... there's still plenty on their roadmap that would continue to improve soundness and expressiveness.

> You can’t have anything approaching ocaml correctness when in typescript all objects with the same shape are interchangeable.

Could you elaborate? Flow has recently switched to exact objects by default[1], which I would have thought would be enough for a sound approach?

[1] https://medium.com/flow-type/on-the-roadmap-exact-objects-by...

Something which I think could be helpful for the overall ecosystem, and allow both type systems to coexist and thrive, would be more attention put into tools which transpile code and type definitions between the two languages. The two most popular projects that I could find[1][2] are unfortunately incomplete and have not received any real updates in months.

[1] https://github.com/joarwilk/flowgen [2] https://github.com/bcherny/flow-to-typescript

So, I was one of (or I suppose the only...) person in the linked issue arguing that competition is useful, and that it makes sense for Facebook's products to be tied into the same ecosystem.

As others have mentioned, when Flow was first launched, TS had an extremely limited type system (e.g. no null checking, no union types). Of course this has improved a lot over time, as the two have converged, but there's still a long way to go for either project to allow JS reach the level of correctness and expressiveness of, say, OCaml or Haskell.

Flow has consistently for the past few years been bringing new ideas to the table from this algebraic data types background, which often have ended up proving to be good ideas, and are in various stages of trickling down to TS.

I worry that if the ecosystem becomes completely dominated by TS, the overall focus will end up back where TS started: rudimentary OOP inspired types, without the underlying goal of overall correctness, which Flow strives for, while TS openly eschews in favour of "pragmatism".

This is currently a stage 1 proposal for the core language: https://github.com/tc39/proposal-optional-chaining

Depending on your stack it might be possible to make use of it already, e.g. Babel has a transpilation plugin, and Flow supports it for static type-checking.

As Dan said when closing that issue, this seems to me how I would expect rendering in React to work... it's async by nature.

If you need the component's state/props to be a certain way for the very first render, use `this.state = {...}` in the contructor, or wait until the Redux store is in the correct shape before mounting the component. (I'm guessing this is what you've done in your HOC, so this sounds like the right solution to me).

Calls like `dispatch` and `setState` shouldn't be expected to reflect in a component's rendering synchronously. And as far as I know, as of Fiber, componentWillMount is even going to become a method that could be called multiple times before the component actually mounts... its usage is pretty widely discouraged for most cases: https://github.com/facebook/react/issues/7671

Why use componentWillMount and not componentDidMount? From the docs:

> componentWillMount() is invoked immediately before mounting occurs. It is called before render(), therefore setting state synchronously in this method will not trigger a re-rendering. Avoid introducing any side-effects or subscriptions in this method.

> componentDidMount() is invoked immediately after a component is mounted. Initialization that requires DOM nodes should go here. If you need to load data from a remote endpoint, this is a good place to instantiate the network request. Setting state in this method will trigger a re-rendering.

> Option 1: Use a string or null/false data [...] If you're using a type checker like #flow, it will yell at you and for a good reason: data type changes are hard to reason about and very error prone in practice.

This isn't true. Flow is great at enforcing that all potential types/values are handled in an if statement. If the following type was used, the code missing the failure case would have been picked up by Flow:

    type Pics = 'fetching' | 'failed' | Array<Pic>

> Option 2: use an object with two props [...] someone accidentally changes the status without changing the data. Or the other way around. This will result in nasty and hard to debug issues where the state and data don't match visually.

Again, this can be avoided by using the correct union in Flow, which will pick up right away if the two properties have become inconsistent:

    type PicsState =
      | { status: 'fetching', list: null }
      | { status: 'failed', list: null }
      | { status: 'fetched', list: Array<Pic> }

I'd highly recommend using a type system like Flow to enumerate the shape of possible actions the store should support. This brings numerous advantages:

1. You can use strings for action types, no more need to import constants.

2. No need for action creators for simple actions, you can just create the action object inline and Flow will validate its shape.

3. You can be sure that reducers are unpacking properties that actually exist from the actions.

In other words, your example could simply be:

    // types.js
    type Action =
      | { type: 'ADD_TODO', text: string }

    // TodoList.js
    dispatch({ type: 'ADD_TODO', text })

...and Flow would confirm at 'compile time' that it matches the contract dispatch expects.

This approach has scaled up extremely well for me and no longer feels verbose.

Maybe what some people are looking for in a replacement, this is something I put together:

https://nachapp.com

It isn't multi-user, but does introduce features around tying tasks to larger goals, progress tracking etc. It's also currently just a web app, but at the moment I'm working on native iOS/Android apps.

Something this article glosses over is that JavaScript achieved all the benefits of ES6, ES7, gradual typing, etc, without breaking backwards compatibility. I can still pull in a library written 10 years ago alongside my fancy new async/await code.

Perhaps this can be partly credited to JS's decision to go with a more minimal standard library, meaning it didn't end up with the Python 2/3 situation as standards evolved.

React Native is primarily aimed at writing cross-platform UI code. When it comes to performance critical code, or integrating heavily with native UIs (eg the media streaming abilities of Spotify) it's perfectly fine to drop down to native code. RN provides an easy way to bridge between the JS and these native components.

Nope, sorry, I'm fully focused on the SaaS model. If it helps at all, I've tried to remove as many concerns as I can associated with storing these kind of things in something cloud-based. See the list of pledges on the homepage, and the privacy policy.

Thanks! Not at the moment. It would be nice to one day, but given that I'm bootstrapping, the rate of growth is quite slow, and I don't think it's reached the scale yet where it would make sense to do full-time.

Self-developed solution that gives a hierarchical structure to to-dos, reminders, and related information:

https://nachapp.com

For anything which I can't figure out a way to tie to one of my current goals, a helpful general rule of thumb is that, it may not actually be that important to hold on to. There are of course exceptions, but they're few enough that a nice folder structure on my hard drive can catch the rest.

I've been using Pinboard for a while as a bookmark list, but find the lack of any structure beyond tags a bit limiting. Just feels like I'm dumping links for the sake of it and will never really end up referring to them again.

I approached this problem and decided to try and solve it for myself just over a year ago. Firstly, I decided that instead of knowledge being segregated by medium (notes -> evernote, bookmarks -> Chrome, etc), it should be organised by purpose.

The most important purpose, I decided, was personal goals. Knowledge/information which is relevant to helping me achieve my own goals is the most important thing I should be focusing on, and should be extremely well organised and easily accessible. Any other interesting info that falls outside that is a bit of a shame to lose, but ultimately just a distraction and clutter. For this purpose, I developed this tool: https://nachapp.com

I believe the next level of information down would be general learning/knowledge. Stuff that doesn't fall under any specific goals, but is still useful information to know and understand (and may in disparate ways tie into core goals). For this, I'm currently using https://pinboard.in, although it's not ideal as it's again limited to a single medium. I have a solution in mind, but haven't started developing yet. If you're interested, feel free to get in touch and I can keep you updated (contact info in profile).

For freelancing, Harvest, which fits my needs perfectly.

For personal projects, I don't believe time tracking to be useful (instead I just track completed tasks).

Agreed. The site now... looks more like every other site. But why's that a good thing? Old design had a more unique personality -- new one looks very much like a Bootstrap deploy with tweaked colours.

Minecraft is tricky because it gives that long-term feeling of accomplishment (the same you get by creating a real-world artwork, or developing a software project), but it's not immediately obvious to some how untransferrable that time investment is to any real value or skills.

Something that can really help with this is getting out of the mindset of identifying yourself by your achievements. You talked about stoicism and being in the present, but it sounds like you're very preoccupied and anxious over how others will percieve your potential success/failure.

One of the aspects of experiencing the present moment is cutting away that ego - realising that ego isn't actually part of conscioussness, it's just something you're choosing to cling onto and identify with.

That doesn't mean that you can't pursue goals and achievement - just that you're not tying them to your happiness. To quote Power Of Now by Eckhart Tolle (which you may want to consider reading):

"Does it matter whether we achieve our outer purpose, whether we succeed or fail in the world? // It matters to you as long as you haven't realised your inner purpose. After that, the outer purpose is just a game that you may continue to play simply because you enjoy it. It is also possible to fail completely in your outer purpose and at the same time totally succeed in your inner purpose. Or the other way round, which is actually more common: outer riches and inner poverty, or to 'gain the world and lose your soul'. Ultimately, of course, every outer purpose is doomed to 'fail' sooner or later, simply because it is subject to the law of impermanence of all things. The sooner you realise that your outer purpose cannot give you lasting fulfillment, the better. When you have seen the limitations of your outer purpose, you give up your unrealistic expectation that it should make you happy, and you make it subservient to your inner purpose."

I realise there are others that likely have much more severe manifestations of the symptoms than me, but I don't think it's quite as black and white as you're making out. Surely the line you describe as "full-blown clinical ADHD" is somewhat arbitrary, when the symptoms exist on a spectrum?

I didn't attempt to get myself diagnosed, but yes, it was a significant impairment towards my life, and yes, there still is quite a negative impairment. If I wanted to get routine tasks done with any kind of consistency, I may well have to look into medication.

But instead, I structured my life around a very diverse range of stimulating past-times, and set myself up with very few obligations (e.g. no employer). This leaves a lifestyle of jumping between stimulating and challenging activities, which allows me to be a lot more productive, and achieve much more, than I ever did when I was in formal education or working a repetitive office job.

> In my direct and social experiences, however, those with clinical ADHD diagnoses are assisted with such suggestions, but very rarely do they improve things to the point that there is no longer a significant impairment to that person's life.

How far did they take the suggestions? Did they quit their job and start their own startup? While I agree that medication is probably the best solution for certain types of lifestyle, I do think adjusting one's environment is an underrated and underexplored solution, that could do with more research.

This is pretty much the same approach I took to largely overcome ADHD-like symptoms. I happen to believe that, if you've fallen into a routine, it's time to re-evaluate, anyway - so the tactic of engineering a more stimulating environment seems like a great idea regardless.

Nice to see someone else viewing pledges as a potential solution.

Something I think would make this even better, is if the pledges were standardised, so they followed some mutually agreeable guidelines. I had a go at doing this here:

https://github.com/jamesisaac/pledges

I have it in place on my app (https://nachapp.com), and plan it include some/all of the pledges on future products I launch. Haven't yet come in contact with any other founders who are up for including it on their product... but if you like the idea and want to help improve the draft (even if it's just for the "long-term service" pledge), feel free to get in touch.

"Ads or subscription-based" is a false dichotomy though. There are many other options (https://gist.github.com/ndarville/4295324) which don't require excluding those who can't pay, and don't, as the quote describes, revolve around getting people to click more ads.

I think you'd find that would make it better, because the top results would no longer be ads belonging to the highest bidders, but would actually be the most useful and relevant links.

Yes, you can avoid this by having an adblocker installed or being savvy enough to recognise what is and isn't an ad, but that doesn't apply to the majority. Just did a search now with adblock disabled, and 70% of the page is taken up by ads that look extremely similar to organic results.

Can't find the link right now, but there was a well documented case about companies who buy Google ads for things which should be provided free via the government, and slap a large processing fee on top of it. These companies end up making big yearly profits by duping people who don't know any better, and trust Google to show them relevant results, not realising that it's actually showing them the most lucrative results first.

Yeah that one might not bother you, but it's just one example... there are many more ways, some a lot more subtle, that having a primary focus of ad revenue degrades the quality of products.

Well, agreed that they don't directly work on those problems, but as far as I'm aware, these companies make no profits from "products, open source work, and research" - it's practically all from the advertising which can be integrated with, or come as a result of, those ventures.

I'm not looking to discredit the work of talented individuals at those companies - just pointing out that the driving force behind where innovative efforts are focused by senior management is likely to be what can generate the most ad revenue.

That was my interpretation of the quote - so not a literal "they all spend most of their time thinking about ads", but "they're employed by a company whose success is driven by how many ads get clicked".

That's only really the case in mature fields (e.g. compsci), but the article pointed out several newly emerged fields, where yes, you could well create a significant discovery just by sitting and thinking about it (providing you have a decently broad background knowledge).