Add Vue js into the codebase #2182

chmelevskij · 2020-09-23T20:28:12Z

POC for using view without even build tool and making it talk with the rest of the code. Idea is to figure out best way for gradual refactoring.

src/vue/init.js

src/vue/logo.js

McGiverGim · 2020-09-24T07:26:03Z

Hi @chmelevskij ! Thanks for this !

In the latest months we have discussed several times to "modernize" the Configurator framework. The problem is that we not decide to which framework we must to go.

I don't have experience in any of the modern frameworks, so I'm not able to argue in one direction or other.

Here there is another POC of adding React for example: #1769 made by @ademuk some months ago.

@mikeller I've seen in the forums a growing interest in the latest weeks to migrate to modern frameworks. Maybe is the moment to choose one, that can be used incrementally. Have you some opinion about what must be our final framework?

I'm sure that any of you @chmelevskij @ademuk @TomChe @DusKing1 @pevecyan @haslinghuis @freshollie (with his complete test to rewrite it https://github.com/freshollie/fresh-configurator) and many others have more knowledge about this.

Maybe you can explain why choose vue, react, other to help us decide? Feel free to invite anyone with knowledge in the theme to discuss in this thread.

chmelevskij · 2020-09-24T08:03:09Z

@McGiverGim I've put this up in the Slack for a poll (as you might have seen). I'm personally a full time React developer so Vue is not my strongest.

I've seen the rewrites, the main issues with complete rewrite are:

It needs a lot of man power, I've worked on projects with money put into it, it still took ages. Free project doesn't have that.
Work is done in parallel, means there is no way to verify with current users that what is shipped is valid. We will need to rely on early adopters.
If it belly flops for some reason, you end up with half baked versions.

So why Vue and not React?

Some of the reasons choosing Vue

Tooling

As you can see in this PR, vue has a modern module output, fact that we are using NWjs means we don't even have to have tooling at first. We don't need to explain to people how to build some special syntax.

Reactivity system

Again as you can see in my PR, Vue has really easy way to plug in model into current code. With react it doesn't come with that straight out of the box, a lot of time would be spend on arguing what to use etc.

Future, styles

It's possible to gradually introduce the tooling and allow single file components, what solves the scoped css issue, again no need for choosing 3rd party solution.

Why not Electron?

NWjs is perfect for this usecase, it has direct access to serial and also supports chromeOS.

Migration

I've seen people talking about fancy rewrites and etc. IMO this project will benefit from those ideas, but it would take ages to do that. With this approach it is possible to focus on the UI part first. Gradually migrate to how just the representaion is handled. No changes to the code responsible of the logic. Once that is in place then it would be time to rearhictect the app, split it into packages or whatever you want. But again doing this gradually. That way project would have verification after every tiny change.

I'll sit down and write proper RFC and create it in Issues once I get a chance.

What about typescript?

Once again, my full time job. So why not to use it? Extra build tooling and familiarity for other developers. Typescript is dead easy to drop in if you have build pipeline. So once vue would use some tooling, typescript would follow.

McGiverGim · 2020-09-24T08:26:57Z

As you have seen in my comment, we don't want a fully rewrite because we don't have enough developers to do that. That is something we have clear. The code needs it, specially the html and css part, but we don't have the power to do it. The incremental approach is needed. Let's see if we can move to components with this incremental approach and see if more developers want to help if we have a more modern framework.

I've seen the comparison WARNING: FROM THE VUE PAGE if someone wants to look at it: https://vuejs.org/v2/guide/comparison.html

If you are a React developer and you think Vue can be better, is a very valuable opinion.

Let's see what others think. Thanks for this again. As I say, we are for the migration, incremental, only need to decide the destination :)

McGiverGim

Only some comments, I've played a little with the vue tutorial and I have some doubts. Maybe this review with questions help to understand what is the final idea.

locales/en/messages.json

src/js/main.js

src/vue/logo.js

McGiverGim · 2020-09-24T11:08:52Z

src/vue/init.js

+import vueI18n from "./i18n.js";
+
+const logoModel = {
+    CONFIGURATOR: CONFIGURATOR,


If this object logoModel is only for the logo component, I think is better to pass only the minimum data that it will need. It makes it easier to understand and easier if we use the minimum variables and not complex objects that we don't use. Maybe in a future we want more, but until then pass the complete CONFIGURATOR object seems too much.

So I think is better to pass only a versionConfigurator (or configuratorVersion if you apply my other suggestion). Something like:

configuratorVersion: CONFIGURATOR.version,

BUT I've tried and it does not get attached to the variable and I think it will not react automatically when we change the CONFIGURATOR.version when loading. I'm very newbie to this. This can be achieved easy in some way o do we need to refresh the configuratorVersion in the same way we do for the other model variables?

I will grab a look, I think it should be fine with smaller object. This was just the shortest path to get what I want 😆

Ok have a try and I see what's happening. So Vue uses some js getter/setter magic to make objects reactive once you pass them to the Vue instance.

Since version is primitive it's passed by value so Vue has no idea that CONFIGURATOR has changed.

In general yes, components should know least amount possible. There are at least 2 ways approach this:

Keep it as a complex object. Once more or even all components are migrated more components will need access to CONFIGURATOR. Also it's important to remember logo component receives primitive strings

betaflight-configurator/src/vue/logo.js

Line 4 in 210cc16

props: [

. Only the root #logo

betaflight-configurator/src/main.html

Line 158 in 210cc16

<div id="logo">

of it receives CONFIGURATOR, once more components are implemented single root will have more and more components which would need access to those values so this would make more sense.

other option would be to update the model in a similar way to

betaflight-configurator/src/js/main.js

Line 747 in 210cc16

window.vm.firmwareVersion = firmwareVersion;

There are other ways to achieve this of course. But I like the current one since it hooks up into current system quite easy.

With that being said, I think it would be even better idea to pass some of the other global objects like FC.CONFIG. This way that would even remove this

betaflight-configurator/src/js/main.js

Line 745 in 210cc16

function updateTopBarVersion(firmwareVersion, firmwareId, hardwareId) {

function all together

True, this is something that needs to be decided. Not a problem for now. Let's see if some experienced Vue developer goes here and gives his opinion.

src/vue/init.js

McGiverGim · 2020-09-24T11:36:40Z

src/vue/i18n.js

+
+i18next.on("initialized", () => {
+    vueI18n.setLocaleMessage("en", i18next.getDataByLanguage("en").messages);
+});


Introducing this vue i18n for translations will complicate things a little... we don't use the i18next library directly because we have first a chrome app and we use the chrome way for pass parameters in the messages file, was positional, with arrays, etc.
If the vue i18n give us benefits is not a problem, but maybe we need to modify some translations when we add it to the vue way.

There exists vue i18next version as well. But I've chose this one because other one currently doesn't have the ESM compliant build.

The main reason to use this is to get translations like $t("versionLabelConfigurator.message") in the Vue templates. i18next seems to have decent event system implemented so it's quite easy to make them two talk. Eventually this would need the refactor of course. But I think that would be more beneficial to do once all of the UI is in Vue( or well any other framework.

What I say is that precisely we use i18nex but with some "wrapper" to maintain compatibility with the old chrome way for some of the old messages that use it:

betaflight-configurator/src/js/localization.js

Lines 62 to 86 in 59076c0

i18n.getMessage = function(messageID, parameters) {

let translatedString;

// Option 1, no parameters or Object as parameters (i18Next type parameters)

if ((parameters === undefined) || ((parameters.constructor !== Array) && (parameters instanceof Object))) {

translatedString = i18next.t(`${messageID}.message`, parameters);

// Option 2: parameters as $1, $2, etc.

// (deprecated, from the old Chrome i18n

} else {

translatedString = i18next.t(`${messageID}.message`);

let parametersArray = parameters;

if (parametersArray.constructor !== Array) {

parametersArray = [parameters];

}

parametersArray.forEach(function(element, index) {

translatedString = translatedString.replace(`$${(index + 1)}`, element);

});

}

return translatedString;

};

Not a big problem, but we need to take it into account.

chmelevskij · 2020-09-24T20:50:41Z

@McGiverGim I've updated the code with more stuff ported to Vue.

One improvement thought it's possible to sort of mix and match vue with existing code. As you see now the whole app is conatiner for Vue. This wrapping could be shrunk down just to widgets or even single instances like I've previously had or keep it on the main content and just gradually adding Vue components.

As you can see even old jquery code still works inside of the Vue instance.

McGiverGim

Thanks for the code, now it explains better how it can work in a future.

The only problem is that now the PR is bigger.

I liked the old because it was very simple to show the POC how to integrate. But I suppose it does not demonstrate the power of the reactive thing. We were using a method like in the old code.
I like the new because it shows how it must work for real with more elements in the UI.

I think remember we have some elements that need some kind of conversion when going from the MSP value (FC variable) to the UI and the inverse. I suppose all of this can be done easily. But this and a lot of other things is better to wait for the final adoption.

But let's go part by part. Let's see if we choose Vue or React and then I hope you can help with some example of more things.

I've talked with @mikeller and I think we agree that is a good moment to take the decision.

src/js/fc.js

chmelevskij · 2020-09-25T09:11:56Z

Yep, it's quite big, but definitely shows the beauty of Vue low level entry barrier for adoption. Especially the fact that currently a most of the stuff had initial values, so that made it super easy to add.

Like I've mentioned before, I do spend my working hours on React code, and just don't see it being that easy to adopt. A lot of decisions would have to be made about things like, how to connect the state? How to style, how to add build tooling?

Could try implementing the same parts in react, but not really keen 🤣 Defo will take longer to setup

atomgomba · 2020-09-25T09:24:32Z

My personal opinion is that React was made to suit Facebook's needs, specifically to make their desktop notifications work. This was clearly stated in the initial demonstration when React was revealed. I do agree that the initial design constraints required to employ React in a project are too far stretching.

chmelevskij · 2020-09-25T09:31:06Z

I mean I love react, it's easy to reason about because of unidirectional data flow and all. BUT, it was made by a massive giant having a full time team working on it. Everywhere I've worked I'd personally spend reasonable amount of time configuring it, choosing tools to go with it and so on. This was a paid job. Also you can design Vue application to have this unidirectional data flow as well. It's no re-inforced though, but that gives team ability to decide.

No one here is really paid to do this. So I think the fact that vue has router, state managment, styling and tooling coming from the same team means there is less time bike shedding, should we use this css-in-js or that one? Should we use mobx or redux, or .

atomgomba · 2020-09-25T09:41:24Z

Unidirectional data flow is a concept and as such it is not tied to any language or framework or whatever. For this reason I don't think it is a real advantage of React over something else. EDIT: Just drop RxJs into any project and basically you're done :)

chmelevskij · 2020-09-25T10:58:14Z

Unidirectional data flow is a concept and as such it is not tied to any language or framework or whatever. For this reason I don't think it is a real advantage of React over something else. EDIT: Just drop RxJs into any project and basically you're done :)

It's not, sure, but in react it's pretty much the only way to deal with data 😉

haslinghuis

Add space

src/css/dark-theme.css

src/js/port_usage.js

haslinghuis · 2020-09-26T00:16:10Z

Anyway, I think Vue (with TS) is a valid way to go forward. Imho only Aurelio is competitive

chmelevskij · 2020-09-26T05:10:13Z

I think TS would be cool as well. And most frameworks support it so it's could be separate PR

chmelevskij · 2020-09-27T16:46:06Z

@McGiverGim @mikeller Is there any progress in thinking about this? Is there any more code, examples or questions?

McGiverGim · 2020-09-27T18:29:28Z

No, all is clear. I've talked about it with mikeller and we will announce the final decision soon 😁
The real job sometimes takes us all the time and the things go slow...

mikeller · 2020-09-28T11:54:50Z

@chmelevskij: Yes, looking into this, along with other potential options like React. One thing that will have to happen first is that we will have to drop support for the Chrome web app version of configurator, as Vue would need to be browserified to run in it.

chmelevskij · 2020-09-28T12:43:54Z

@mikeller Sorry, I don't understand what you mean with:

One thing that will have to happen first is that we will have to drop support for the Chrome web app version of configurator, as Vue would need to be browserified to run in it.

So you want to drop Chrome app support, because Vue needs to be browserified? Doesn't sound right...

Modern browsers already support <script type="module" > as I've even done in this PR. Browserify is quite unnecessary here, considering that application ships with up to date runtime it can work without extra bundling. Some packages will some tidy up, rollup is way much better choice.

In general, I think when it comes to modules/bundling the aim should be to work towards using native esm modules.

Do you need an example in React then? Could try to ramp one up for the same codebase, but it will be a bit more involved, because, well, it's react 😅 so would need another week or two. But if that would help with decision happy to do it 😉

chmelevskij · 2020-09-28T13:02:22Z

What just worries me is that this spreadsheet been created almost a year ago now. By this point it doesn't really matter that much which one you pick. But it's about time to choose one 😅 Otherwise there be more and more forks and rewrites seeing how the main project is stuck in choosing the best framework.

McGiverGim · 2020-09-28T13:43:59Z

@chmelevskij no, we don't need a React POC, we have another one that I linked in the conversation. What I think @mikeller wanted to say is that the decision has been slow because he has being comparing both.

And yes, we want to remove the old chrome support. Some things like import do not work. We are talking about chrome apps, not that it do not work in chrome browser. You can test loading the dist folder as extension in chrome and it gives a lot of headaches to maintain at the same time that node.js. We want to get rid of it too in the process.

This architecture decision follows a process, internal discussion, etc. please wait some time more. I want to have it available for hacktoberfest, is a good way to get some PR that use it, but I can't promise nothing...

chmelevskij · 2020-09-28T13:54:09Z

cool, sorry if I sound to pushy. Just putting out questions to see if I can be of any help 😊

One thing which I've mentioned before is that migration to some js framework shouldn't be that strongly tied to the re-architecture of the whole app.

Also chrome extensions are not exception for type="module" it works in extensions as well 😉 The only thing with them is that they have contexts in which you can use certain things and apis.

McGiverGim

Added some little comments to the review too.

Another question: I've seen that there is an extension for Vue that can be installed in Chrome to help debugging... can this extension be installed in our node/nw system in some way? Will be very valuable to have tools that help with the code.

McGiverGim · 2020-09-28T13:55:23Z

src/js/main.js

-    updateTopBarVersion();
+    // with Vue reactive system we don't need to call these,
+    // our view is reactive to model changes
+    // updateTopBarVersion();


We don't like to have commented code. I understand that for the POC is useful but please remove it before the final version.

Yep, more for the illustration of Vue 😉 put it so that I didn't forget to comment it.

In general. Will tidy up and split the commits if it comes to merging this.

This commentary remains, please remove it. I think is the latest to approve it (at least in my side).

McGiverGim · 2020-09-28T13:59:50Z

src/js/serial_backend.js

-        $('span.cpu-load').text('');
+    // TODO: vue would need to check the version as well somehow
+    // if (semver.gte(FC.CONFIG.apiVersion, "1.20.0"))
+    //     $('span.cpu-load').text('');


This is only a reset. I don't now why it resets the contents of the CPU load based on the version. Maybe it is not needed in earlier versions, but it does not hurt neither. I suppose that now that they are reactive we reset them when we reset the FC object. So we only need to be sure that the FC object is being reset when before we show the fields.

McGiverGim · 2020-09-28T14:06:43Z

src/vue/status-bar/port-utilization.js

+    filters: {
+        stripEnd(value) {
+            return value.replace(/\$1%/, "");
+        },


This hack needs to be fixed in a better way:

One solution is to "migrate" the messages phrases to be compatible. The only problem with this is that all the translators will need to change the translations too, and this is a big work.

The "hack" must be only at one place. Now you are adding this to any component with the problem, this is not a good way.

I'm not too sure what this replacement does exactly. Can you explain better what the problem is with one example?

I think the "best" solution would be to just use appropriate formatter for i18nvue. Default one uses {token} syntax, but it's possible to just write custom one which would use the same syntax as i18nnext.

about multiple places. It's possible to register filter with single component or just the instance. Could easily pull this out if needed to just the status bar.

Messages had CPU load: $1% in them, this strips that end part so that you don't get CPU load: $1%20% etc. in status bar.

(more info about custom formatters)[https://kazupon.github.io/vue-i18n/guide/formatting.html#custom-formatting]

chmelevskij · 2020-09-28T14:48:36Z

Another question: I've seen that there is an extension for Vue that can be installed in Chrome to help debugging... can this extension be installed in our node/nw system in some way? Will be very valuable to have tools that help with the code.

It should be possible, I've done similar thing with puppeteer in the past, so doubt that nwjs will be different.

In general I'm thinking about few improvements for DX:

formatter like prettier, maintainers shouldn't worry about put space here, or new line there it's unproductive
recommit hooks, clean and tidy up code before even it hits PR.
Some better reload/debug experience. Current approach (or at least the only one I've found) of rebuilding after every change is a bit cumbersome.

So yeah, there are some thoughts on how to improve DX in general 🙃

mikeller · 2020-09-28T19:22:14Z

@chmelevskij:

Modern browsers already support <script type="module" > as I've even done in this PR. Browserify is quite unnecessary here, considering that application ships with up to date runtime it can work without extra bundling. Some packages will some tidy up, rollup is way much better choice.

Yeah, not quite:

[Vue warn]: Error compiling template: invalid expression: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' blob: filesystem: 'wasm-eval'". in CONFIGURATOR.gitChangesetId Raw expression: :git-changeset-id="CONFIGURATOR.gitChangesetId" 176| <div id="content"></div> 177| </div> 178| <status-bar :port-usage-down="PortUsage.port_usage_down" :port-usage-up="PortUsage.port_usage_up" :packet-error="MSP.packet_error" :i2c-error="FC.CONFIG.i2cError" :cycle-time="FC.CONFIG.cycleTime" :cpu-load="FC.CONFIG.cpuload" :configurator-version="CONFIGURATOR.version" :firmware-version="FC.CONFIG.flightControllerVersion" :firmware-id="FC.CONFIG.flightControllerIdentifier" :hardware-id="FC.CONFIG.hardwareName" :git-changeset-id="CONFIGURATOR.gitChangesetId"></status-bar> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 179| <div id="cache"> 180| <div class="data-loading"> (found in <Root>)

chmelevskij · 2020-09-28T19:55:14Z

@chmelevskij:

Modern browsers already support <script type="module" > as I've even done in this PR. Browserify is quite unnecessary here, considering that application ships with up to date runtime it can work without extra bundling. Some packages will some tidy up, rollup is way much better choice.

Yeah, not quite:

[Vue warn]: Error compiling template: invalid expression: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' blob: filesystem: 'wasm-eval'". in CONFIGURATOR.gitChangesetId Raw expression: :git-changeset-id="CONFIGURATOR.gitChangesetId" 176| <div id="content"></div> 177| </div> 178| <status-bar :port-usage-down="PortUsage.port_usage_down" :port-usage-up="PortUsage.port_usage_up" :packet-error="MSP.packet_error" :i2c-error="FC.CONFIG.i2cError" :cycle-time="FC.CONFIG.cycleTime" :cpu-load="FC.CONFIG.cpuload" :configurator-version="CONFIGURATOR.version" :firmware-version="FC.CONFIG.flightControllerVersion" :firmware-id="FC.CONFIG.flightControllerIdentifier" :hardware-id="FC.CONFIG.hardwareName" :git-changeset-id="CONFIGURATOR.gitChangesetId"></status-bar> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 179| <div id="cache"> 180| <div class="data-loading"> (found in <Root>)

Do you have a repro branch by any chance or instructions on how to reproduce?

These errors are not module related, it's error about how Vue templates are rendered in the extension. It's possible to enable the eval or sometimes specify the hashes for the js.

Another solution which would work as well I think is to use Vue compiler at build time.

WalcoFPV · 2020-10-07T20:15:02Z

Apart that, Vue seems to work well with Cordova

McGiverGim · 2020-10-07T20:37:31Z

Thanks @WalcoFPV for your help with this. Glad to know that Vue works ok with Cordova.

chmelevskij · 2020-10-10T17:00:01Z

Can somebody with android test this out? @WalcoFPV ?

WalcoFPV · 2020-10-10T17:32:14Z

Can somebody with android test this out? @WalcoFPV ?

There is an issue with the logo of the sidemenu

src/vue/betaflight-logo/BetaflightLogo.vue

mikeller

One comment about string templating. Apart from that the code looks good to me.

What I would like to discuss is the proposed way forward with respect to the folder structure. I don't think that what we currently have (html hangs directly off /src, everything else is one layer down from it) isn't a good way of doing things. So I think we should be considering if there is a better approach than adding another type of source in its own subdirectory.

Re casing, my personal preference is for PascalCase over kebab-case. But that's just that, a preference.
From practical experience, most modern file systems seem to be able to handle case sensitive file names sufficiently well, so I don't see a problem there.
However, the case insensitivity of html is an issue here - to me, introcuding a mapping between PascalCase entities in code and kebab-case equivalents in html is not a good approach, as it makes it harder for developers looking at code to find all occurrences of a particular entity, so I think using consistently using kebab-case for entities that are used in html templates is a better approach.

The obvious other thing that we need to look into is to make this work for the android version.

gulpfile.js

chmelevskij · 2020-10-11T06:47:36Z

The obvious other thing that we need to look into is to make this work for the android version.

Fixed that (I think) just need a second pair of eyes best if with a real device to verify it.

File structure and casing issues are kind of related.

PascalCase doesn't work in *.html files. But eventually *.html files wouldn't hold any Vue code. General suggestion is to use runtime only version of vue, and compile templates at build time. This means in *.html you'd only have <div id="app" /> or few of them and templating would be done in *.vue files. But for transition it's fine to have compiler in the prod build.

Similar to the casing, most of the structure would gradually move from nested src/**/*.(css, img,js,html) files to vue/**/*.vue components. IMO once the considerable amount of app is migrated it will be possible to just drop vue and place components in the src directly. I originally though about using components folder instead. But it's already there and having Components and components isn't great idea. But replacing Components with this PR would mean even more changes .

McGiverGim · 2020-10-11T07:05:11Z

However, the case insensitivity of html is an issue here - to me, introcuding a mapping between PascalCase entities in code and kebab-case equivalents in html is not a good approach, as it makes it harder for developers looking at code to find all occurrences of a particular entity, so I think using consistently using kebab-case for entities that are used in html templates is a better approach.

I think the recommendations of Vue is to do exactly that, PascalCase always except for html, so I suppose the developers do it in this way and is how the developers will expect to find it. If they recommend this way I suppose it has not produced any problem in the latest years.

mikeller · 2020-10-11T07:10:05Z

@chmelevskij:

Similar to the casing, most of the structure would gradually move from nested src//*.(css, img,js,html) files to vue//*.vue components. IMO once the considerable amount of app is migrated it will be possible to just drop vue and place components in the src directly.

Where do you think the pure .js componentry for the backend of the application should live in your proposal?

chmelevskij · 2020-10-11T07:23:04Z

I imagine a flatter src moving things like src/js/msp to the src/msp similar for other stuff. Could have src/backend/ if there are more related components.

Currently html css and js is very split up for every UI related feature. Once they are componentized doubt there will be that many loose packages. And the ones which are left will be significant enough to have it's own folder/namespace.

mikeller · 2020-10-11T07:36:35Z

@chmelevskij: Makes sense. But not sure if we want to stick these components into a /src/vue/ for the transition period.
Should we do the rename of /src/Components into /src/Components to make it comply with kebab-case, and then use this going forward? /src/Components is relatively new and contains only one component, so the effort will be relatively low.

WalcoFPV · 2020-10-11T10:05:28Z

Fixed that (I think) just need a second pair of eyes best if with a real device to verify it.

Logos are fixed on Android !

McGiverGim

Only one minor change in this review
The old change request of the older review about removing a comment that remains in the code.

For the rest, to me is ok. We can always change a thousand things, but we need to start with something.
About moving it to Components it seems the Vue Style Guide use components in lower case.

gulpfile.js

Setup vue with gulp and initial components: * Status Bar * Logo * Battery Legend

sonarqubecloud · 2020-10-14T15:53:06Z

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

No Coverage information
1.0% Duplication

McGiverGim

@chmelevskij to me this is approved! Thanks for your patience all this time with this PR.

TheIsotopes · 2020-10-15T07:03:05Z

package.json

  "default_locale": "en",
  "scripts": {
-    "start": "gulp debug",
+    "start": "NODE_ENV=development gulp debug",


This breaks yarn start on windows 10 ... @chmelevskij pls can you check whats wrong

The "NODE_ENV" command is either misspelled or could not be found. error Command failed with exit code 1. info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Sorry, don't have access to windows. How do you set environment variables in windows usually?

set VAR=VALUE

TheIsotopes · 2020-10-15T07:03:10Z

package.json

+    "start": "NODE_ENV=development gulp debug",
    "gulp": "gulp",
-    "release": "gulp release",
+    "release": "NODE_ENV=production gulp release",


same as above

Please try this PR #2226

working again ... thx @atomgomba

chmelevskij · 2020-10-15T07:38:04Z

@TheIsotopes will add https://www.npmjs.com/package/cross-env tonight 😉 Sorry about that

atomgomba · 2020-10-15T07:40:56Z

@chmelevskij there is an alternative package and it seems to provide a more readable syntax to solve this: run-script-os: https://docgov.dev/posts/npm-scripts/#possible-solutions

haslinghuis requested changes Sep 24, 2020

View reviewed changes

src/vue/init.js Outdated Show resolved Hide resolved

src/vue/logo.js Outdated Show resolved Hide resolved

McGiverGim reviewed Sep 24, 2020

View reviewed changes

chmelevskij force-pushed the chore/add-vue branch 2 times, most recently from 68c812d to e064761 Compare September 24, 2020 19:25

chmelevskij force-pushed the chore/add-vue branch 2 times, most recently from ae8a4e9 to 585d0c4 Compare September 25, 2020 07:11

McGiverGim reviewed Sep 25, 2020

View reviewed changes

src/js/fc.js Show resolved Hide resolved

haslinghuis requested changes Sep 26, 2020

View reviewed changes

src/css/dark-theme.css Outdated Show resolved Hide resolved

src/js/port_usage.js Show resolved Hide resolved

McGiverGim reviewed Sep 28, 2020

View reviewed changes

chmelevskij force-pushed the chore/add-vue branch 2 times, most recently from 510ad7d to 6c7b37a Compare October 10, 2020 15:36

WalcoFPV reviewed Oct 10, 2020

View reviewed changes

src/vue/betaflight-logo/BetaflightLogo.vue Outdated Show resolved Hide resolved

src/vue/betaflight-logo/BetaflightLogo.vue Outdated Show resolved Hide resolved

chmelevskij force-pushed the chore/add-vue branch from 6c7b37a to c6d7a58 Compare October 10, 2020 18:10

mikeller reviewed Oct 11, 2020

View reviewed changes

gulpfile.js Outdated Show resolved Hide resolved

chmelevskij force-pushed the chore/add-vue branch from c6d7a58 to 960760d Compare October 11, 2020 06:30

McGiverGim requested changes Oct 13, 2020

View reviewed changes

gulpfile.js Show resolved Hide resolved

Add Vue

d6cee38

Setup vue with gulp and initial components: * Status Bar * Logo * Battery Legend

chmelevskij force-pushed the chore/add-vue branch from 960760d to d6cee38 Compare October 14, 2020 15:51

McGiverGim approved these changes Oct 14, 2020

View reviewed changes

mikeller approved these changes Oct 14, 2020

View reviewed changes

mikeller added this to the 10.8.0 milestone Oct 14, 2020

mikeller added the RN: FEATURE label Oct 14, 2020

mikeller merged commit 7fcc9ef into betaflight:master Oct 14, 2020

TheIsotopes reviewed Oct 15, 2020

View reviewed changes

atomgomba mentioned this pull request Oct 15, 2020

Fix npm scripts on Windows #2226

Merged

	i18n.getMessage = function(messageID, parameters) {

	let translatedString;

	// Option 1, no parameters or Object as parameters (i18Next type parameters)
	if ((parameters === undefined) \|\| ((parameters.constructor !== Array) && (parameters instanceof Object))) {
	translatedString = i18next.t(`${messageID}.message`, parameters);

	// Option 2: parameters as $1, $2, etc.
	// (deprecated, from the old Chrome i18n
	} else {

	translatedString = i18next.t(`${messageID}.message`);

	let parametersArray = parameters;
	if (parametersArray.constructor !== Array) {
	parametersArray = [parameters];
	}
	parametersArray.forEach(function(element, index) {
	translatedString = translatedString.replace(`$${(index + 1)}`, element);
	});
	}

	return translatedString;
	};

Uh oh!

Uh oh!

Add Vue js into the codebase #2182

Add Vue js into the codebase #2182

Uh oh!

Conversation

chmelevskij commented Sep 23, 2020

Uh oh!

Uh oh!

Uh oh!

McGiverGim commented Sep 24, 2020

Uh oh!

chmelevskij commented Sep 24, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

So why Vue and not React?

Tooling

Reactivity system

Future, styles

Why not Electron?

Migration

What about typescript?

Uh oh!

McGiverGim commented Sep 24, 2020

Uh oh!

McGiverGim left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chmelevskij commented Sep 24, 2020

Uh oh!

McGiverGim left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

chmelevskij commented Sep 25, 2020

Uh oh!

atomgomba commented Sep 25, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chmelevskij commented Sep 25, 2020

Uh oh!

atomgomba commented Sep 25, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chmelevskij commented Sep 25, 2020

Uh oh!

haslinghuis left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

haslinghuis commented Sep 26, 2020

Uh oh!

chmelevskij commented Sep 26, 2020

Uh oh!

chmelevskij commented Sep 27, 2020

Uh oh!

McGiverGim commented Sep 27, 2020

Uh oh!

chmelevskij commented Sep 24, 2020 •

edited

Loading

McGiverGim left a comment •

edited

Loading

atomgomba commented Sep 25, 2020 •

edited

Loading

atomgomba commented Sep 25, 2020 •

edited

Loading

chmelevskij commented Sep 28, 2020 •

edited

Loading