This document contains rules and guidelines for porting the library from Java to TypeScript.
Local development using Node.js and npm or yarn, see package.json for dependencies.
Note: Keep dependencies at minimum necessary. 🖤
To run the docs, open the CLI in this project root folder (something like <somepath>/zxing-js/library):
user@computer BUILDV <somepath>/zxing-js/library (develop)
http-server ./docs -a localhost -p 4040 -oNote: http-server is a package that runs a local server, install with npm i -g http-server.
Initial port from 3.3.1-SNAPSHOT on May 2017 by Adrian Toșcă (@aleris).
The Java files are transformed using regexps for some obvious syntax transformation (see ./autotransform) and then modified manually.
Using http://www.jsweet.org was considered but rejected because of loosing type information early on (for example number versus int is essential for bitwise operations), language style and older TypeScript version.
- Keep all types as close to the original as possible.
- Keep detailed type information in comments where applicable (example int will become
number /*int*/) as the code is extensively using bitwise operations that can overflow. - Use TypedArray whenever possible (example
int[]will becomeInt32Array) - see below for more info. - Use constructor property whenever possible.
- Take care of array initialisation with capacity, especially when using length and push later on. Basically only use when setting with index accessor only .
- Use utility classes to implement platform dependencies (like
SystemorArrays), avoid inline implementation for anything that is not trivial. - Use single class|enum|interface per module, export with default. Move internal classes to separate modules if used from other modules.
- Package level visibility will transform to public to avoid module complexity.
- Keep enum as similar with the original interface as possible (transform to class and use static fields for enum values).
- Always use
===for==to avoid glitches from type transforms.
| Java | TypeScript |
|---|---|
byte[] |
Uint8ClampedArray |
int[] |
Int32Array |
https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html
bytehas 8 bits, signed (e.g. -127 to 127), sobyte[]would transforms toInt8Arrayhowever:TextEncoderwill useUint8Array.canvasimage data will useUint8ClampedArray.
inthas 32 bits, signed, soint[]transforms toInt32Array.charhas 2 bytes, sochar[]transforms toUint16Array.longhas 64 bit two's complementinteger, can be signed or unsigned.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray
- Take care of
int->number(integer to number) port when doing bitwise transformation especially<<. Do a& 0xFFFFFFFFfor ints, a &0xFF for bytes. - Take care of array initialization, in Java
new Array(N)initializes capacity NOT size/length. - Use
Math.floorfor any division of ints otherwise thenumbertype is a floating point and keeps the numbers after the dot.
In Java new String(<ByteArray>, encoding), a lot of encodings are supported
See StringEncoding.ts for implementation in TypeScript for handling limited browser support.
Will became: StringEncoding.decode(<ByteArray>, encoding).
- Check for
sometype[]arrays: check for push, check for==length etc. To spot size comparison bugs. - Skipped:
BufferedImageLuminanceSource.javacommon/AbstractNegativeBlackBoxTestCase.javacommon/AbstractBlackBoxTestCase.java
Cp437not supported by TextEncoding library seeDecodedBitStreamParserTestCase.- Replace
instanceofwith something more robust. - Simplify double
null !== <something> && undefined !== <something>checks.
Most of things here are opinions and were written by the first porter, please feel free to discuss and help us to make it better.