Well, I'm just going to assume there are no tests surrounding the code. As a newcomer, you're going to be fairly unfamiliar with how things work, so one of the things you could do write tests that assert existing behaviour. This gets code under test, gets you familiar with how things work right now, and gives you a base from which to refactor. In general, an "if it ain't broke, don't fix it" approach is the pragmatic one in your situation, but but there are going to be times when stuff is broken and needs to be fixed. In that case, you might expand the scope of the fix to include a refactor of that specific component. The peril there is when your refactor starts to sprawl unnecessarily or excessively. If you feel like maybe your refactor has begun to necessarily expand its scope beyond what you anticipated, it's time to re-evaluate just how pragmatic it is to refactor at all.

I'll say something like "derp".

I sit cross legged most of the time. Sleeping in a hammock will help with back pain.

Persisting data locally can be done via AsyncStorage, which is simply a container for key-value pairs of string, string. So you'll use a key (hopefully prefixed by the app id and logged in user id) and a JSON.stringifyed object. Pull it out and JSON.parse it and you're good to go. If you're using Redux, the library redux-persist helps facilitate that. If you want a custom implementation, you can write your own redux middleware (which is pretty easy to do). If you're using MobX, check out Mobx State Tree. Persisting data remotely is not the domain of React Native. It will interact with an API (unless you're interrogating a remote database directly).

It sounds like you want to protect the actual license key from being traffic snooped. So you want the user to be able to authenticate to the API somehow and then acquire the license key from it. Perhaps you could use a shared secret to encrypt the key.

Consider the scope of your current work. If you can't pin your changes to that scope, save it for later. If the refactor is significant, judge its worth. It depends upon how problematic the existing code is. If your refactor makes things easier to change / work with / understand in the future, it's probably worth it.

That's similar in nature to idiomatic .NET. There, you use an underscore to denote a private class variable, camel case for method parameters and standard variables, and UpperCamelCase (aka PascalCase) for public / protected members.

Working code.

I like ArangoDB

What's the problem with using numbers to start off a branch? I usually start the name of my ephemeral feature branches with the associated work item number.