We are building a react native receipt printing app, and we don't run test cases

@jAsE this is thermal paper. So there's no ink :D

@irene we have a complete stock management saas built on react. My boss feel it will be easy to port it into a react native app.

@jAsE the bridge part for Bluetooth and js did took me sometime to sort out :(

@irene No js is your only salvation! Btw I'm writing typescript using visual studio code on a macbook. Can't imagine what the world will become

@irene used to really hate js in uni, since my tutor told me js is not a proper programming language. Nowadays I think they not real programmer either LMAO

Your boss is an idiot and there has to be someone on your team who has a real education and isn't just another react fanboy brogrammer who can set him right.

@jburleson the app has shipped and it's working perfectly so far. Since no one has been started using it yet.

@sunfishcc react always works best when not being used by anyone

Is there a software development paradigm called reactive or I just invented?

@irene we got let, const for scoping. Typescript enum will compile to number areay in js. Properties under class will be undefined if no initial value. When using typescript, it almost feel like you are writing C++ with an easier syntax. Node.js uses chrome's V8 engine. Think about it. V8, how fast is that! Lmao

🍎🍏🍎🍏🍎🍏

@irene So we did benchmarks with native Swift vs. React Native (to see what the performance trade-offs were) and the results were almost identical. In certain cases (GPU), Swift did slightly better and in other cases (memory), React Native did better. I did dig a little deeper and found that the react components were basically abstractions for the native iOS/Android components. Of course, you should always choose the right tool for the job, and there are certain downsides to React that you won't find in Native, but overall it seems fine. We did a sample app in React Native and found that the code reuse between the two platforms were the highest we've ever had, which means we spent less time rewriting components and interfaces and only having to do minor platform dependent tweaks.

Phew, that was long.

What are you even trying to do?

@c3ypt1c idk. Followed the orders?! Maybe? 😹

@monkehparade I agree! Every task which is more resource intensive can still be outsourced to a native module (bridge), but the code reuse can be immensely.

Last year we implemented a web, android & iOS app. The JS part of the project was structured into a common, native and web folder where the native and web folders contained almost all of the React.Components (view specific code so to say). The application state code (redux) and side effect code is for about 80-90% the same across all platforms.

We encountered the biggest differences in handling logins and background processes, which are naturally different between web and native.

And the greatest thing is, every dev in our company is capable of ES6/7, React and the redux patterns. So if shit hits the fan and we have to fix something for a customer, it is easy to find one who can do it (at least if there are supposedly no native modules involved).

@finiteAutomaton the bottom menu used to be an iOS only thing. It's hard to implement in Android. With react, this becomes so easy. Spotify uses react native, you can't say music player is not a hardware intensive task on mobile.

@sunfishcc i mean like, what's the projects ultimate goal? :/

@c3ypt1c the orchard hires hundreds of overseas seasonal workers to pick apples. There will be at least 2 people pick a bin and 60 bins load in a truck. About 500 bins per day. There's no cellular signal in the orchard, neither WiFi. So they hire lots of managers just to record these data. Our goal is to simply this process by providing an app works offline to print labels using Bluetooth, and then sync data once the truck back to storage.

@sunfishcc okay, makes sense c:

@c3ypt1c those seasonal workers are sneaky. The number never add up since they usually report more than they did. 🙄

@sunfishcc haha, this!

Having to prove your software works when the numbers don’t add up is my life. Like yes, it says 600 came in but you only 400 went out, this is because your cheap labour workers don’t care about your business.

Quick! Scan his QRs!

@brod not my business, we only developing software. Many local orchards are owned by global organizations.

@sunfishcc oh yeah, didn’t mean it like that..

@brod no problem. I just a junior developer I don't care 😎

I use QZ, but React native sound great!

@xewl what's QZ?

@sunfishcc Java based, see QZ.io

@xewl interesting I will take a look.

@sunfishcc We use it for order fulfilment, our warehouse management is completely web based. QZ makes it possible to connect to a QZ tray instance over websockets (javascript library included in demo files) and send pdf, images, EPL, ZPL and even HTML (with JavaFX) to (a/the selected) printer. It's open source too 🤩 check their demo for example code ;)

@xewl we also have a saas, but the goal for this app is to print labels offline. Since most of orchards don't have wifi nor phone signal. React-native-camera uses object recgnition function in Java, definitely not the fastest, but seems most commonly used in react community.

@sunfishcc QZ can run on the local computer too, it'll open some localhost websocket ports.

My app finally deployed for alpha testing. Got complains about can't find back button.
It's an Android app, and Android phones have a dedicated back button.
Oh geez...
iPhone users are killing me 😂
BTW: they got a free Samsung A6 for testing.

UPDATE: the app receives positive feedbacks. The orchard want to invest more. So we decide to add more features and connect it to our desktop app.
By we, I mean my boss decided, and I'm writing the code to support it.

I once had to do this in linux. Horrible cheap clone printed, ended up reverse engineering a lot of it and replacing cups (cups is really bad for controlled printing). We kept having reports every now and again of things like half and over printed receipts. No print server but it was suppose to handle concurrency. Had to test with concurrent printing to try to brute force the issue sending a thousand prints all at the same time. Just sat then and watched the printer spill its guts into a huge pile on the floor.