Make editor plugins look inside node_modules to load Merlin editor support.

Currently, this is how the editor support is loaded (please correct my Emacs knowledge)

Vim/Emacs: We require that you put in your .vimrc a line that adds the global OPAM switch to the search path for plugins. That opam switch has the core Merlin support for Vim/Emacs/Atom, and the opam switch also has the Reason plugins as well. So we tell Vim users to add a bunch of lines bunch of lines that result in the right directories being in Vim's search paths.

Atom support is a lot more elegant. The user only needs to install one wrapper/dummy plugin called atom-reason-loader, which basically searches for your opam switch automatically.

Now that merlin may now be installed as an npm dependency of your project, we can improve the plugin loading experience in the following ways.

[ ] Make two wrapper plugins, that do what atom-reason-loader does by dynamically loading the real editor plugin intelligently based on installation of Reason/merlin. But let's do better than atom-reason-loader. Instead of just searching the global opam switch, let's search the closest reasonable node_modules directory for the first .re/.rei file opened.

[ ] Create wrapper plugin for Vim
[ ] Create wrapper plugin for Emacs
[ ] Enhance atom-reason-loader wrapper plugin that already exists for Atom.

Currently, this is how the editor support is loaded (please correct my Emacs knowledge)

Vim/Emacs: We require that you put in your .vimrc a line that adds the global OPAM switch to the search path for plugins. That opam switch has the core Merlin support for Vim/Emacs/Atom, and the opam switch also has the Reason plugins as well. So we tell Vim users to add a bunch of lines bunch of lines that result in the right directories being in Vim's search paths.

Atom support is a lot more elegant. The user only needs to install one wrapper/dummy plugin called atom-reason-loader, which basically searches for your opam switch automatically.

Now that merlin may now be installed as an npm dependency of your project, we can improve the plugin loading experience in the following ways.

[ ] Make two wrapper plugins, that do what atom-reason-loader does by dynamically loading the real editor plugin intelligently based on installation of Reason/merlin. But let's do better than atom-reason-loader. Instead of just searching the global opam switch, let's search the closest reasonable node_modules directory for the first .re/.rei file opened.

[ ] Create wrapper plugin for Vim
[ ] Create wrapper plugin for Emacs
[ ] Enhance atom-reason-loader wrapper plugin that already exists for Atom.

We discovered that it should be as easy as:

Upon first opening of .re, .rei, .ml, .mli, do the following:

Search for the closest ancestor that has a package.json with an node_modules folder in it.
From within the editor process:
Run the following shell command eval $(./node_modules/.bin/dependencyEnv) which will augment the PATH with all the right locations that include ocamlc/ocamlopt/refmt/ocamlmerlin/ocamlmerlin-reason etc.
Then and only then should ocamlmerlin be started.

Then everything should work just as well as it does today! It should be pretty easy if you know how to execute the output of dependencyEnv inside of the editor process, so that all forked processes will have the updated PATH.

I uploaded a very early version for emacs here:
https://github.com/yunxing/yarn-reason

I have also done something similar to what @jordwalke described for the vscode plugin. However, I think it would be a bit cleaner if we could get dependencyEnv to just spit out key-value pairs (at least as an option) instead of having it run and modify the environment itself. That way you can just set the intended environment directly when spawning the child process.

Is it more difficult to set the environment variables by running dependencyEnv?

@jordwalke I think so. Giving an example with node (which affects the vscode plugin) you can't just use child_process.spawn anymore to start merlin.
One alternative is to use child_process.exec and do something like dependencyEnv && ocamlmerlin but that causes problems for the communication process with merlin due to exec buffering the IO. If you start merlin this way and try to use readline, eventually the process will die.
The other way is to stick with child_process.spawn but call sh -c "dependencyEnv && ocamlMerlin" instead of ocamlmerlin. But this seems more fragile and likely to fail on certain systems than if you could just get the key-value pairs and only call spawn.

Are any of the editors already supporting this? Trying to get reason running locally, failed to install opam.. but the npm version works great. However, struggling to get any of the editor (atom, sublime) integration going.

@KidkArolis the vscode extension works this way now. For the other editors, I think you need to start them with npm run editor to pre-configure the environment.


What's the proper way to inject table view cell loaded view registerNib and dequeueReusableCellWithIdentifier?

Sorry, this is not an issue, but I couldn't find a better forum.
What's the proper way to inject table view cell loaded view registerNib and dequeueReusableCellWithIdentifier?
The easiest way I've found is the following, but maybe you have a better way?
UINib *nib = [UINib nibWithNibName:@"FooCell" bundle:nil];
[tableView registerNib:nib forCellReuseIdentifier:fooCellIdentifier];

UITableViewCell *fooCell = [tableView dequeueReusableCellWithIdentifier:fooCellIdentifier];

TyphoonComponentFactory *factory = [TyphoonComponentFactory defaultFactory];
[factory inject:fooCell];

return fooCell;

Here's the correct solution for now: http://stackoverflow.com/a/28620601/404201
In future we might make a shortcut.

Thank you

You're welcome :)

as well as the implementation will be on Swift?


Update a full document

MongoDB allows to update a document with a command or a doc:
http://docs.mongodb.org/manual/reference/method/db.collection.update/#replace-all-fields
In some version the driver lost this posibility.
The patch adds a solution for this problems.

@comtihon   any clues to get this into master ?

I'll check this in a few days.

Hello,
I've updated the code to avoid conflicts, but seems that in mater the test suite is broken.
Regards.

Sorry for a long delay. As far, as I can see - todays master branch is suitable for your needs without this commit.
As for oldest commits - I still can't figure out, why do you need changes to not returning list in prepare and assign. As far as I remember - if you specify command without <<"$set">> - document will be completely updated.


support GitHub-style namespacing (org/repo) for bower register

for #1857

It's already possible to install via org/repo syntax. I would assume you can reuse the convert url logic from that instead of writing your own convertGitUrl

@mohsen1 thanks your suggestion,I found install via org/repo is only available the repo in github,but repo is not only in github,maybe it is in bitbucket,my solution is fetching the first remote address that the list of git remote -v

A test, please :)

Superseded by #2248


Inode quota support

What is the problem you're trying to solve
Prevent containers from using a large number of inodes and exhausting system memory.
Describe the solution you'd like
Allow for configurable inode quotas that prevent container images from using more than the inode limit.
Additional context
Hostile processes in unprivileged containers can abuse the lack of inode quotas to by creating e.g. a very large nested directory trees, to exhaust system memory and render the node unstable:
https://github.com/kubernetes/kubernetes/issues/106083

https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

While not completely water-tight, all major memory usages by a given cgroup are tracked so that the total memory consumption can be accounted and controlled to a reasonable extent. Currently, the following types of memory usages are tracked.

Userland memory - page cache and anonymous memory.
Kernel data structures such as dentries and inodes.
TCP socket buffers.

Wouldn't it be covered by cgroups?


Enforce us-east-1 usage for SSL certificates

Fixes #75.
Otherwise this will break, as shown:
Also, can I be given branch access on your repo? I'd prefer working on this repo and making a pull request that way or whatever, forks aren't really appropriate as you're basing the end template on S3 and I'd rather use that.
By the way, please see https://github.com/ks888/LambStatus/issues/74 as that will greatly enhance testing.
Thanks

Thank you for your PR! It looks good.
For branch access, do you mean collaborator access? If so, I'm very sorry but I can't for now. Before that, I'd like to share the design and implementation of LambStatus with you more through issues and PRs.


Adding Filename into Winston Logger

Hi,
I'm using a shared Winston Logger across my project and I was wondering if there was some way in Winston to add the filename the logger is being called from? For example if I use log.info in foo.out, is there some way to show in the log that that statement was from foo.out?
Thanks,
Rohit

Also this is a duplicate of #200.

Thanks. This will be addressed via custom formatters in 3.0.0

I didn't found instruction in documentation on Creating custom formats, Have you an example in my case ?
const winston = require('winston')

const {
	format: {combine, timestamp, json}
} = winston

const config = {
	levels: {...},
	colors: {...}
};

winston.addColors(config.colors);

const myformat = winston.format.combine(
	winston.format.colorize(),
	winston.format.timestamp(),
	winston.format.align(),
	winston.format.printf(info => `${info.level} ${info.timestamp} : ${info.message}`),
);

winston.configure({
	levels: config.levels,
	format: combine(timestamp({format: 'YY-MM-DD HH:mm:ss'}), json()),
})

if (process.env.NODE_ENV === 'production') {
	winston.configure({
		transports: [new winston.transports.File({filename: process.env.API_LOG_FILENAME})]
	})
} else {
	winston.configure({
		transports: [new winston.transports.Console({
			format: myformat
		})]
	})
}
```


[e2e-testing][Appium] Adding support for android:id

Calling view.setId() with the matching resource-id of an id found in R.class when BaseViewManager.setTestId is called.
Adding TestIdUtil in common to store mappings for testID with attributed views and their original react tag value.
Changing the signature for Event Classes to require the View instead of the viewTag.  This reduces the number of locations where TestIdUtil.getOriginalReactTag is called.
Overriding BaseViewManager.onDropViewInstance to perform TestIdUtil mapping cleanup.
This closes #9777.
In order for this to work properly, an id resource needs to be manually added to android/app/src/main/res/values/ids.xml.  Here's the contents of that file:

<?xml version="1.0" encoding="utf-8"?>
<resources>
<item name="something" type="id"/>
</resources>

By analyzing the blame information on this pull request, we identified @kmagiera and @sebmarkbage to be potential reviewers.

Not sure why one of the xcode builds failed:

@ide what's the best way I could test this change?

Building from source and running the UIExplorer + temporarily modifying its code to invoke your new code is a reasonable path forward.

Thanks @ide !
I've verified locally that it works!

I also verified that non-existent ids in ids.xml don't have any side effects i.e. testID="some-id-not-in-ids.xml" doesn't break anything.

cc @mkonicek

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

Looks like the tests for HMR are failing on most PRs.

Yeah, trunk was broken over weekend.
Should be fixed now

I'm pretty wary of setting the id on views because we at least use the id of the ReactRootView to track the ReactRootViews so this can break something in a hard to track way...
I can't remember off the top of my head if we the ids of non-ReactRootViews else where though...

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

I'm pretty wary of setting the ids on views because we at least use the ids of the ReactRootViews to track the ReactRootViews so this can break something in a hard to track way...

Is there an example of where a ReactRootView would ever have a testID?  I'd like to test that in JSX if possible.
I could add a check and only set the id if view.getId() == 0.

@jsdevel updated the pull request - view changes

@AaaChiuuu I added an additional check to avoid setting the id on the view if it's Id isn't 0.

Hold off on approving, testing my latest changes locally...

@jsdevel updated the pull request - view changes

@AaaChiuuu I see what you mean about the existing usage of ids.  Seems like perhaps the code responsible for setting view IDs should avoid clearing out it's existing ID.
I'm not really sure what to do at this point.  I feel it's a major problem for me and others to not have resource-id available for testing purposes.

So, after digging around for a while it seems that the best place for resource-id support may not be in this repo at all.  It could actually be here https://github.com/facebook/react/blob/334b8bdf165c47336b467a4092e3f51893a83c0d/src/renderers/native/ReactNativeBaseComponent.js#L66.

I'm still looking into the impact of this change.  Currently it's looking like ReactShadowNode is where the tag matters.  Everything after that doesn't seem to matter so much as the views use dom related methods to gain access to parents etc.
/me still digging...

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

Added some unit tests.

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@AaaChiuuu I've added an approach that could work for preserving the original tag without too much overhead.  Let me know if you like this approach or not.

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@AaaChiuuu @bestander @ide @mkonicek
I've added documentation, unit tests, and I've scoured the code pretty well.
I have one open question about events that I'd like to have answered before this gets merged (See the TODO).  Other than that it feels like a fairly stable change and it works great for me locally.
Please let me know if you have any feedback that you'd like me to address.  Support for resource-id is something I (and I'm sure others) really need right now for automation purposes.
/me awaiting your reply

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@AaaChiuuu is more familiar with this code and how it integrates with facebook's apps. One thing I'm a little wary of is making sure everyone uses getOriginalReactTag instead of getId everywhere, @AaaChiuuu probably has a better sense than I do whether that's actually a problem or not.

@ide is there a way of detecting __DEV__ in the java code?

I don't think that works.

BaseViewManager#setTestId in theory shouldn't ever be called when __DEV__ === false.  It would also be nice if TestIdUtil#getOriginalReactTag could simply return view.getId when __DEV__ === false.

@jsdevel updated the pull request - view changes

One thing I'm a little wary of is making sure everyone uses getOriginalReactTag instead of getId everywhere

@ide I made an update that should cut down on the number of places getOriginalReactTag would need to be called.  Mainly around events.
I also think I've answered my TODO question around events.  Am I correct in assuming that the tag associated with an event to be emitted back to javascript needs to correlate to one created in react?

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

BaseViewManager#setTestId in theory shouldn't ever be called when DEV === false. It would be nice if TestIdUtil#getOriginalReactTag could simply return view.getId when DEV === false.

I realized that if no testID has been used that getOriginalReactTag can simply return view.getId().  That should make it much faster in non __DEV__ envs.

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

It's working in the e2e tests now!

@jsdevel updated the pull request - view changes

Good job, @jsdevel!
I'll send a not to the team, I think this is an important change, hope this does not break any existing apps.

Good job, @jsdevel!

Thanks @bestander !  Let me know of any concerns.

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

Two issues with this PR, still not sure this is the right approach but if Appium can't look up views by tag we might have to do something similar to this PR.

Appium isn't able to look up views by tag (see this thread).

The pull request is very large. Can you limit it to the absolute minimum needed for the feature, without changing all integration tests?

Done.  I've removed as much as possible including the changes to the generated app and the e2e tests.

How hard is it to get Appium to look up views by tag? At fb we use a custom e2e testing framework which supports looking up views by tag.

According to the thread link I posted earlier, it seems like it's a very long process.  It's also dependent on uiautomator2 which isn't shipping with studio right now.

How does this work on iOS? Can Appium find the views based on testID out of the box?

According to the thread link I posted earlier, findViewById works on iOS.
Thanks for the review @mkonicek!  I believe I've made all the changes you've requested.

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@jsdevel updated the pull request - view changes

@mkonicek just thinking about this some more:

If we used setTag for the react tag then we could avoid TestIdUtil.getOriginalReactTag and maintaining a map of identityHashCode to react tag.
Doing this would break your internal e2e testing framework, but I'm sure it could easily be migrated over to using findViewById instead.
This approach would be easier to manage and would be more performant in non prod envs.

@jsdevel updated the pull request - view changes

@bestander @mkonicek any update on this?

@jsdevel updated the pull request - view changes

@jsdevel, @mkonicek went on vacation, I'll pick up from this.
Please give me a couple of days to clean up some hi pri stuff and I'll get back to you.
Don't hesitate to ping me :)

@jsdevel, @mkonicek went on vacation, I'll pick up from here.
Please give me a couple of days to clean up some hi pri stuff and I'll get back to you.
Don't hesitate to ping me :)

:dancers: :dancer:  Thanks @bestander ! :confetti_ball:

@jsdevel updated the pull request - view changes

+1

I think this is an important change for the people who is using appium to automate.
Thanks @jsdevel for doing this.
+1 to prioritise this to unblock many of us

ping @bestander

@bestander @mkonicek any chance this will get merged soon?  Any more feedback?

Hey Joseph, I'll do my best to find some time, sorry for a delay.
Your PR is on my list
On 4 October 2016 at 06:59, Joseph Spencer<EMAIL_ADDRESS>wrote:

@bestander https://github.com/bestander @mkonicek
https://github.com/mkonicek any chance this will get merged soon? Any
more feedback?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/pull/9942#issuecomment-251302887,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACBdWEhapqClJl6R_cUr4TGc1-uMa0Lsks5qwes3gaJpZM4J-zyB
.

Thanks!

Hi @bestander.  I hope all is well.  I'm really desirous to see this get merged as my testing efforts are blocked without it.  Any chance this will be merged soon?  Are we waiting for the current release to be cut?

@jsdevel great job!
Let's shipit, sorry for a delay

Considering that you just pushed a change can you fix a couple of more nits I added?
After tests pass I'll merge it.
Hope internal code tests won't break, otherwise I'll be merging those on Monday.

@facebook-github-bot import

Thanks @bestander !  I made the changes you requested!

@facebook-github-bot import

@bestander I'm not sure why a few of the xcode builds keep failing.  I don't believe it's related to my changes.

@facebook-github-bot shipit

@jsdevel yeah, that is expected, those two middle tests are flaky right now, we'll address this next week.
I looked at how import goes, there are some changes needed in internal FB Java code around the new Event constructor.
It looks like a breaking change and all the opensource apps would need to upgrade their events.
Do you have something clever in mind that would not require patching all Events for React Native?

I suppose an additional constructor could be added to accept int instead of View.

An alternative here is to use setTag for the react tag instead of setId; however, doing that would likely break your internal e2e and it would also require casting to int which is more dangerous.

How about the second constructor?
On Friday, 7 October 2016, Joseph Spencer<EMAIL_ADDRESS>wrote:

An alternative here is to use setTag for the react tag instead of setId;
however, doing that would likely break your internal e2e and it would also
require casting to int which is more dangerous.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/pull/9942#issuecomment-252361073,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACBdWKlMxXtcignLKFjGzMPopj7eGKWXks5qxrSYgaJpZM4J-zyB
.

Is it too late for me to add that?  I can update this PR if not or open a new one.

Updating is fine, we can reimport as many times as needed
On 7 October 2016 at 22:56, Joseph Spencer<EMAIL_ADDRESS>wrote:

Is it too late for me to add that? I can update this PR if not or open a
new one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/pull/9942#issuecomment-252370595,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACBdWKV7rQuuvd8vFksoJ4a-fg7i1Y6vks5qxsAigaJpZM4J-zyB
.

OK @bestander.  I updated the PR.  Please note that I made quite a few updates to make this back compat.

BTW you don't have to squash commits when submitting PRs.
Our scripts will squash them automatically when PR is merged and it is easier to review multiple commits

BTW you don't have to squash commits when submitting PRs.  Our scripts will squash them automatically when PR is merged and it is easier to review multiple commits.

Thanks for clarifying!  I'll stop squashing then.  It'll be easier to revert ideas that get bounced back and forth.

@bestander what would the internal effort be to re-write android e2e tests to use id instead of tag?

I don't know yet, React Native is used in internal products and they may
choose many kinds of e2e solutions.
It is a matter of trying and fixing what breaks.
On Saturday, 8 October 2016, Joseph Spencer<EMAIL_ADDRESS>wrote:

@bestander https://github.com/bestander what would the internal effort
be to re-write android e2e tests to use id instead of tag?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/pull/9942#issuecomment-252412473,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACBdWBpX01kV5lndLSxZ11CoePGBjx9Aks5qx1mdgaJpZM4J-zyB
.

The thing is that updating apps between React Native is already painful
enough.
Considering that this feature won't be used by majority of people I would
rather find a way for those who want to use it to opt in rather than
introduce a breaking change.
I think manual patching of all views or events is not the right way.
On Saturday, 8 October 2016, Joseph Spencer<EMAIL_ADDRESS>wrote:

@jsdevel commented on this pull request.
In ReactAndroid/src/main/java/com/facebook/react/uimanager/
events/ContentSizeChangeEvent.java
https://github.com/facebook/react-native/pull/9942:

@@ -16,12 +18,26 @@
private final int mWidth;
private final int mHeight;

/**

See {@link Event#Event(int)}.

@param viewTag

@param width

@param height

*/
@Deprecated

I don't think this scales well.
I agree. I was originally thinking I could make this work with a
deprecated constructor in Event.java; however, I realized that all of
these events are exposed publicly.
Do you have an idea how we could make events and tags work without
patching any of them?
Not really. I struggled with this because I wanted to avoid the
duplication. Any plugin that creates a ContentSizeChangeEvent with the
view tag would break without this constructor.
I think the @Deprecated constructors are needed. Perhaps they ship with a
few releases, then get removed with the hope that plugin maintainers have
the chance to update their code?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/pull/9942, or mute the thread
https://github.com/notifications/unsubscribe-auth/ACBdWGpQ1qn_UKxoqIImI7cvmdDH7CTUks5qx1hngaJpZM4J-zyB
.

I don't know yet, React Native is used in internal products and they may choose many kinds of e2e solutions.  It is a matter of trying and fixing what breaks.

Reason I ask, is that if we use setTag for the react tag instead of setId, we can avoid changing the signatures of all these events and TestIdUtil altogether.

I would rather find a way for those who want to use it to opt in rather than
introduce a breaking change.

Let me add a commit to use setTag for the react tag and see how many e2e tests break in the internal apps.

Let's give it a try and see
On Saturday, 8 October 2016, Joseph Spencer<EMAIL_ADDRESS>wrote:

I would rather find a way for those who want to use it to opt in rather
than
introduce a breaking change.
Let me add a commit to use setTag for the react tag and see how many e2e
tests break in the internal apps.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/pull/9942#issuecomment-252416660,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACBdWIdi7cLTDz9PktTedvT3Q-RFrTw0ks5qx22kgaJpZM4J-zyB
.

@bestander see my latest commit.  I'm going to do some testing locally to see if it checks out while the travis build is running.

testID is working locally with a sample app.  Going to add a static helper method to add safety around the casting.

Static helper method added to reduce casting and to re-create the default behavior of View.getId() when no id has been set i.e. return View.NO_ID.

@bestander I made a fix to the one failing test case in the last build.  The circleci tests should pass now.
While using setTag for the react tag instead of the testID is certainly cleaner than having lots of @Deprecated constructors, I realize that is is a backwards incompatible change for anyone who was gaining access to a View and fetching the react tag with getId.   Any code that was calling getId for the react tag would have to change to getTag if we go with this approach.

There are some infrastructure issues currently, can't run the tests
internally
On Sunday, 9 October 2016, Joseph Spencer<EMAIL_ADDRESS>wrote:

@bestander https://github.com/bestander I made a fix to the one failing
test case in the last build. The circleci tests should pass now.
While using setTag for the react tag instead of the testID is certainly
cleaner than having lots of @Deprecated constructors, I realize that is
is a backwards incompatible change for anyone who was gaining access to a
View and fetching the react tag with getId. Any code that was calling
getId for the react tag would have to change to getTag if we go with this
approach.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/pull/9942#issuecomment-252454765,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACBdWDeCf3J7nNAMNjqFFHFc-NbZ6z4xks5qyCvMgaJpZM4J-zyB
.

No worries @bestander.  I've had to deal with those types of issues before.  Let me know when you're ready to pick this back up again.  I can't wait to see it merged!

@jsdevel , thanks for adding these changes. It really helps. Waiting for these change to get merged, so that I can see resource id in appium when test id is added reactNative code.
Btw, does my develpers need to upgrade reactNative to get your changes @jsdevel once your changes are merged?

Btw, does my develpers need to upgrade reactNative to get your changes @jsdevel once your changes are merged?

@s-sridevi15 yes.  They'll need to upgrade to the version of react-native that this change ships with (see react native versions once this is merged).
@bestander what's the status on the infrastructure issues?

I am pulled into Yarn support currently.
@mkonicek is back from vacation, could you please have another look if you
have a chance?
@jsdevel, really sorry that I can't dedicate some time into your PR.
You did a great job and this is important stuff but as you know this
feature interferes with quite a bit of core stuff that is risky to touch...
It would be easier if it touched as little as possible
On 12 October 2016 at 23:59, Joseph Spencer<EMAIL_ADDRESS>wrote:

Btw, does my develpers need to upgrade reactNative to get your changes
@jsdevel https://github.com/jsdevel once your changes are merged?
@s-sridevi15 https://github.com/s-sridevi15 yes. They'll need to
upgrade to the version of react-native that this change ships with (see react
native versions https://facebook.github.io/react-native/versions.html
once this is merged).
@bestander https://github.com/bestander what's the status on the
infrastructure issues?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/pull/9942#issuecomment-253363695,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACBdWISq6eD68kRgTQdTjYghT5ahdNB7ks5qzWZagaJpZM4J-zyB
.

It would be easier if it touched as little as possible

I agree and understand.  I feel the approach with using setTag instead of setId is the most reasonable path forward.

OK @bestander.  I've chipped away at the change set to only include was is absolutely necessary.  If you have time to take another stab I'd love to see this get merged successfully.
cc @mkonicek

maybe off topic - but is there an equivalent to resource-id in ios? If I understand correctly this PR enables to get any android native element by ensuring each testID will map to resource-id. What will be the equivalent in the iOS PR?

@guysegal I haven't tested appium or uiautomatorviewer with react-native on ios; however, several online articles said it works just fine.

@guysegal: name is equivalent to resource-id in ios which is already working for ios with test ids

@grabbou any chance you could merge this?

How is this one coming along?

@ThaJay still waiting for one of @AaaChiuuu, @bestander, @ide, or @mkonicek to attempt another import.

Sorry for the delay, I was off-the-grid. Any updates on doing this without having to change the ids.xml and recompile? Can Appium find views by [Android tags](https://developer.android.com/reference/android/view/View.html#setTag(java.lang.Object), which are set by React Native when using testID?

Removed the accepted label for now to understand whether we need the resource ids and why.

While using setTag for the react tag instead of the testID is certainly cleaner than having lots of @Deprecated constructors, I realize that this is a backwards incompatible change for anyone who was gaining access to a View and fetching the react tag with getId.

I don't understand this - we already use setTag right now, correct?
https://github.com/facebook/react-native/blob/9ee815f6b52e0c2417c04e5a05e1e31df26daed2/ReactAndroid/src/main/java/com/facebook/react/uimanager/BaseViewManager.java#L87

fetching the react tag with getId

What does this mean? What do you mean by "react tag" - is this the testID?

I'll do another review pass 👍

Thanks @mkonicek !
There's been a lot of conversation on this PR.  Sorry for all the chatter.  The commit messages need to be cleaned up as well.  Let me know if you'd like me to do that.
Here's what's going on in the latest approach:

setId used to be used to store the react tag.  This was acceptable being that there wasn't a way to set the id with testID.
Now that we need to use setId for the resource-id aka android:id, it would be burdensome to guess as to whether or not the returned id represents the react tag or the resource id.
To remove confusion setTag is now used exclusively for the react tag, and setId is used for the android:id.

This is no doubt a breaking change; however, it's safer than trying to maintain an internal mapping (from one of my previous commits).

I fixed the conflicts @facebook-github-bot

Thanks for the explanation @jsdevel!

np!  I believe I've addressed your latest feedback @mkonicek.  Take a look and let me know.

Ids should be in the xml file so R.class is generated correctly; otherwise, uiautomatorviewer and appium can't associate it to the testID.

Can you clarify what you mean by "associate it to the testID"? If the ids (e.g. "login_button") are set at runtime only, and in Appium we do a lookup for "login_button", are you saying that Appium can't find the element? I'd expect UI automator to do a simple lookup similar to findViewById at runtime? Does Appium need R.class as well and why?

Thanks for the quick update @jsdevel!

Once this is ready to be merged I'll also need to update our internal e2e testing framework to use ids instead of tags.

@mkonicek appium looks for ids in resources.  In native android with xml based layouts you use android:id which ends up as an id resource in R.class after compilation e.g. <TextView android:id="@+id/nameTextbox"/> can by found with findViewById(R.id.nameTextbox);.  Because react-native isn't using xml based layouts, we need to state the id in ids.xml so appium can then perform a lookup against R.id to grab the integer value.

@jsdevel Ah of course, silly question, sorry! :)
Appium needs to translate "login_button" into an integer, and for that it uses the resources. Makes sense.
Now I'm thinking how we'll do the translation "login_button" -> integer -> view in our internal e2e testing framework. We don't have ids in resources, and when the test code does:
driver.findViewById("login_button")

We'd have to make the test framework call TestIdUtil to translate that into an integer and then look up the view by the integer id. This seems complicated. I'm thinking we can just do View.setTag(0, testId) when setting a testId: https://developer.android.com/reference/android/view/View.html#setTag(int, java.lang.Object)
So at fb each view will store:

tag - React tag
tag(LARGE_NUMBER) - String testId

Outside of fb each view will store:

id - integer id for Appium, corresponding to ids.xml
tag - React tag
tag(LARGE_NUMBER) - String testId (Unused, ideally in the future Appium can use this and we can get rid of ids.xml)

Using the LARGE_NUMBER is a bit of a hack :) http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/5.1.1_r1/android/view/View.java#17293

setTag(LARGE_NUMBER, stringTag)

@mkonicek I can try that later tonight.  Looks like View has findViewByTag which would allow for findViewByTag("login_button") (at first glance).

Supporting Appium and the fb testing framework at the same time is getting quite complicated :(
We could just use setTag(LARGE_NUMBER, reactTag) for react tags, and keep the setTag(testIdString) as before. But that adds memory overhead to every view so it's a no go.
How hard is it to convince someone at Appium to prioritize looking up views by tag?

How hard is it to convince someone at Appium to prioritize looking up views by tag?

Based on comments in their open issues and forum threads I'd say it's a non starter.
How hard would it be to follow a pattern like this in internal FB apps? https://github.com/facebook/react-native/pull/9942/files#diff-3b4df9d6f8274463f67e764159059571R182  That doesn't feel too complicated to me.  In fact I'd bet internal apps at FB can reduce some code by following that pattern.

Thinking about this more supporting both Appium and the fb e2e testing framework at the same time sounds quite complicated.
How about a different approach? Appium uses Selendroid (https://github.com/appium/selendroid) under the hood, and you can add extensions to Selendroid to add support for looking up views by tag. Here is the code of the extension: http://pastebin.com/h5TRLmL9
If you can add that to Appium, it should be possible to send a request from Appium with android_view_tag and Appium will find the element.

How hard would it be to follow a pattern like this in internal FB apps? https://github.com/facebook/react-native/pull/9942/files#diff-3b4df9d6f8274463f67e764159059571R182

Yes, that's an option too although I'm afraid I won't have bandwidth to make changes to the fb testing framework soon :(

@mkonicek so that could work for appium, but then there's uiautomatorviewer and the rest of the testing frameworks out there that may or may not support ways of finding views by tag.  I'd assume the latest version of most testing frameworks support finding view by tag, but it certainly isn't as clean as finding by id.
wd is really the only js framework that has appium support, so we'd also need to add support to that framework as well for finding by tag.

+1 for uiautomatorviewer support . My framework cannot rely on selendroid .

I think it's important to point out that adding support for android:id is really something that solves many issues. I'm pretty surprised it's not already supported by react native. It's a pretty big deal breaker as an android developer to have no control over how my "native" views are rendered in terms of identifiers

I see the point that ids have been the standard way but then you need to add the ids.xml file. One advantage of tags you just do <View testID="login_button" />, React Native sets the tag and e2e tests can look up "login_button".

There's probably a way to avoid ids.xml.   It may be possible to dynamically add the fields to R.class at run time.
As far as moving to selendroid etc.  I don't have any more time to devote to that.  I've spent quite a bit of time on this PR as it is.

@mkonicek after thinking about this further, I feel the following points are worth considering:

every testing framework out there supports findViewById
some testing frameworks out there support findViewByTag

I realize it's more work for facebook to switch to using findViewById in internal integration tests, but it's better for the community IMHO if they do.  We can update one framework (ReactNative) to support EVERY testing framework.

I realize it's more work for facebook to switch to using findViewById in internal integration tests

It's actually not possible I think because we don't use ids.xml with React Native :( I was thinking we could switch to findViewByTag(LARGE_NUMBER) but then I realized adding another tag to each view with a TestID allocates memory which means we shouldn't do that.
I've been thinking more about this and thought we could add a flag - like TestIdMode.TAG or TestIdMode.ID and the behavior in this pull request would only be enabled for the ID mode. For fb apps we'd use TAG so nothing would change. That would mean more divergence in how the internal and open source build work though which generally makes debugging harder - there could be a bug in the open source build and not internal or vice versa.
I suggest for now use the accessibility labels :( or Selendroid which should work fine.

Another option I see is we'd have a way to strip the TestID in production builds of fb apps. Right now the apps shipped to the Play Store still contain the TestIDs stored in each view which is wasteful. Changing the internal test framework to use findViewByTag(LARGE_NUMBER) is still a bit hacky though because the LARGE_NUMBER is supposed to be generated from ids.xml which we don't use.
I think if someone set up and easy-to-use setup for e2e testing that relies on tags, and included that in the app template you get with react-native init so you can just run one command to run the test that would be a cleaner way forward. If I have some time left later this year I think it will be better spent setting up an easy-to-use tooling based on Selendroid that anyone can use rather than working on findViewByTag(LARGE_NUMBER). Or anyone reading this could try take a stab at  it - that would be definitely something we should merge.
As a workaround for if you don't want to set up Selendroid please use the accessibility labels. I know it's not an ideal solution..

I think if someone created and easy-to-use setup for e2e testing that relies on tags, and included that in the app template you get with react-native init so you can just run one command to run the test that would be a cleaner way forward. If I have some time left later this year I think it will be better spent setting up an easy-to-use tooling based on Selendroid that anyone can use rather than working on findViewByTag(LARGE_NUMBER) and making sure the tags don't get included in production builds.
Anyone reading this could try take a stab at creating that easy-to-use e2e testing setup - that would be definitely something we should merge.
As a workaround for if you don't want to set up Selendroid please use the accessibility labels for now. I know it's not an ideal solution..

I feel bad I came to the discussion so late after you've spent a significant amount of time on this PR - most of the discussion happened while I was on holiday, sorry!

@mkonicek I'm not seeing in selendroid's documentation where you can find a view by it's tag value.  All I found was this http://selendroid.io/native.html#tagName, and that appears to be for the tag name i.e. Button.

As a workaround for if you don't want to set up Selendroid please use the accessibility labels for now. I know it's not an ideal solution.

Accessibility labels really are not a solution.  In many cases we need to locate elements that are useless and non-interactive.  Very misleading for the blind.
@mkonicek I'm confused as to why you need ids.xml if you're not currently using selendroid internally.  Can you not follow this? https://github.com/facebook/react-native/pull/9942/files#diff-3b4df9d6f8274463f67e764159059571R182  No ids.xml file is needed if you're accessing views programatically in your tests.  This PR falls back on an internal map to generate id values.

We are using Selendroid internally. Selendroid has support for extensions, here's the one we use to find elements by tag value: http://pastebin.com/h5TRLmL9
We could tweak the testing framework to call into TestIdUtil.getTestId(testId) in RN tests I think.

@mkonicek one of the reasons I placed TestIdUtil.java in common is that it appears you publish common as a java module internally at FB.  If your selendroid extension has access to TestIdUtil, then it should be as simple as changing lines 74-75 of your pasted script to:
      int id = view.getId();
      return id == TestIdUtil.getTestId(mTag);

You could probably take this a step further though and leverage findViewById to make that extension more performant.  Iterating through every view in the hierarchy isn't very performant.  I don't see the definition for findElements (is that an internal method?).  Seems like you could add your own internal method findElementById(request, elementId) and call TestIdUtil.getTestId(elementId) inside that method with rootView.findViewById(TestIdUtil.getTestId(elementId))

If you were to implement by previous comment:

you wouldn't need ids.xml at all.
we could still publish an extension for selendroid users that would have the benefit of not having to manage ids.xml.
your tests would be more performant as you'd leverage findViewById.

That would leave the hassle of ids.xml for everyone else; however, I'm sure it would be simple to write a script that could generate ids.xml from js source pre compilation no problem.

Using TestIdUtil.getTestId in the internal e2e testing framework might work but not sure yet, would have to try if that's possible to call from the Selendroid extension It might be possible using reflection. I also just noticed the TestIdUtil.setTestId has some additional time and memory overhead which will be present in production too.
I still think we should ship a ready-to-use test framework with React Native that relies on Android tags instead.
I have a lot on my plate now so will have to let this one sit for a while, possibly find an owner to ship the testing framework with React Native.
Sorry this is not straightforward to merge and that we didn't have this discussion upfront before you started working on the pull request!
I'll close it for now so people triaging pull requests don't spend time on it but have an internal task to get back to this.

TestIdUtil.setTestId has some additional time and memory overhead which will be present in production too.

How is that possible?  testID is effectively ignored in production is it not?

I still think we should ship a ready-to-use test framework with React Native that relies on Android tags instead.

Why?  There should be solid reasoning behind a statement like this.  There's already been comments on this thread from others stating that they can't rely on Selendroid.

I have a lot on my plate now so will have to let this one sit for a while...

The main hurdle facing contributing to this framework.

possibly find an owner to ship the testing framework with React Native.

So the plan is to introduce yet another testing framework into the community?

Sorry this is not straightforward to merge and that we didn't have this discussion upfront before you started working on the pull request!

I had opened an issue to do this prior to working on this PR, but as you said you have a lot on your plate so is the story with getting feedback prior to working on changes.

I'll close it for now so people triaging pull requests don't spend time on it but have an internal task to get back to this. I'll also bring this PR up at our team meeting next week to figure out an owner for adding the test framework based on Selendroid to RN.

I appreciate the gesture, but I have no faith at this point that that will occur.
I really love react native as a framework, but this PR is a case example of what I dislike the most about the eco system:  react-native is about facebook first, community second.

I tested today with selendroid and selendroid also takes names from accessiblity label , but not from test ids. So selendroid is not a solution and it has same issue as appium.  As Joseph said, this PR should merge as it helps the community and it effects only internal to facebook . Please let your framework to be useful to community, not just internal to facebook .

@mkonicek @jsdevel
IMO creating another testing framework only for this is not a good way. Appium is a defacto standard framework for mobile testing hence there're echosystems and knowledge for it. If RN ignores them and creates another testing framework, it will be a barrier to use RN in terms of E2E testing.

How is that possible? testID is effectively ignored in production is it not?

If the main concern of merging this PR is performance, this is the best way I think.

Hey @jsdevel, sorry this made you unhappy.
After reading the comments above I'd like clarify: my theory is it should be possible to use Appium with Selendroid plus this extension: http://pastebin.com/h5TRLmL9. We should try that first, that would mean no changes are needed to RN, and it should be possible to ship this extension with React Native and make it easy to use. If that doesn't work, other alternatives are:

Open sourcing the testing framework we use at fb based on Selendroid
Reopen this pull request and use on of the approaches we discussed above. We'll need a way to do e2e testing with RN Android.

I'm currently working on the following things, in this order:

Project templates for react-native init to make it easier to get started
Make upgrading easier with revamped react-native upgrade & fixing the release process for library authors

Then the next things in my backlog are (will decide on ordering as I go & with others on the team):

Improving the process of writing 3rd-party modules
e2e testing
WebView (from Product Pains: https://productpains.com/product/react-native?tab=top)
Look into symlink support for packager (from Product Pains)
Look into how ListView could be improved (from Product Pains)

I would welcome if anyone from the community would try to get Selendroid to work with the extension in the meantime: http://pastebin.com/h5TRLmL9

@mkonicek

I agree that it's easier to maintain the framework by storing the react tag with View.setId; however, doing so limits the ability to use testing frameworks that may or may not support extensions or finding view by tag.
I'm pretty sure ids.xml could be generated with a groovy build step if this approach is revisited.

Just wonder how many people were dreaming of this PR to be merged...
Don't think Appium community will change the focus back to Selendroid from UIAutomator just because RN don't see a point to support id. Not logical.
But adding this in RN will definitely improve testability of apps, for now it is still associated with pain and limitations and just scares away.

I have to say that I was following this threas for weeks hoping the PR will merge.. I'm struggling with same issues in our RN app..too bad :(

I have to say that I was following this thread for weeks hoping the PR will merge.. I'm struggling with same issues in our RN app..too bad :(

@dmlemeshko
I guess around 10 people wait for this PR from reactions of this comment or this comment. I'm one of them. E2E testing for Android on my app is blocked by this issue.
There are two reasons to use testID for E2E testing for me.

Robust against layout change
Cross-platform testing (Android and iOS)

The 2. is lack for RN apps now. It's time consuming to write up E2E another test script only for Android. I want to write common test scripts for both Android and iOS. For it, this PR is necessary.

@rhysd
same problem: we have both iOS and Android apps, where RN is about 50% now and all new modules are going be implemented in RN (even old one is planned to be re-written in RN)
And yes, it is not that many RN apps yet and not every app has automation testing coverage, so maybe now we got 10 people here and maybe another 30 not able to find this PR. But the number of RN usage is highly growing and the question of "easy to test" will only become more critical.
I share both of your reasons and moreover, I don't see a point when people may stop using Appium (based on WebDriver that all the way to be w3c standard) and switch to Facebook testing framework that nobody have seen so far just to have stable automation for RN.
My management is curious about RN testability and the feedback they get so far doesn't make them happy. I'm sure our company is not the only one that wants RN apps to be of good quality with short release cycles.
Not totally blocked, but I hope to see any feedback or introduction how to Automate RN app from Facebook perspective to understand what to expect and what approach is the right one.

Yes we really do need proper UI testing indeed. Our company is moving open source and we can't manage contributions without a high code coverage.

we're also struggling with this issue - right now we're deciding which runner we'll use for functional / e2e tests. ( Appium, espresso... ) A consistently supported cross platform solution would be great.
( You guys all use appium? )

Appium as of the official release of 1.6.0 fully supports UIAutomator2
https://github.com/appium/appium/releases/tag/v1.6.0
UIAutomator supports finding by tags, so this should be a none issue now?

@marcin1337
Could you show some links to description that Appium will support finding element by tag name? I could n't find in Appium document or Python binding document.

Appium has an issue for finding by View tag. I wouldn't expect it to happen anytime soon.
I'm disappointed that FB is rejecting support for resource ids. Android testing frameworks expect resource ids to exist as a primary way to locate elements.
It'd be nice if a new API was added to enable this use case of testing react-native apps with existing testing frameworks.

Appium project lead here, didn't realize that lack of view tag support was blocking appium testing of react native apps. I'll schedule an investigation into the linked issue ASAP.

As the guy who started this thread https://discuss.appium.io/t/react-native-ui-element-access-via-testid/7845 nearly a year ago it's probably worth pointing out the solution I ended up going with.
I defined a testProps(id) function which returns an object {testID: id, accessibilityLabel: id}.
It's used in all our RN views e.g.
<View {...testProps('idForThisView')}>
Appium can then find elements by id on both iOS and Android. Yes, the accessibilityLabel is user-visible but testProps is conditional on build type so we only include these props for a test build anyway.
It means we're not quite testing with the exact build we ship, but it's worked well for the last 9-10 months.

Seems like a great solution @jonesdar! Thanks for sharing. I'd also mention that adding a sensible accessibility label "by hand" is also a best practice both in terms of testing and making your app accessible. Having not used RN myself yet I'm not sure exactly what that would look like other than simply:
<View accessibilityLabel="Something Sensible" />

Appium's findElementByAccessibilityId should then be able to find the element quickly and unambiguously.

Accessibility labels should really only be used for UI elements that are interactive.  There's a whole set of best practices around them that have absolutely nothing to do with testing.  Let's keep the blind in mind when testing...

Good point @jsdevel. I often find from an Appium perspective that there's a high degree of overlap between the things you want to have accessibility labels (interactive elements) and the things you want to find for testing. But that's certainly not always the case and it's important to be careful.

The solution is to hide automation only identifiers behind a build type.

I will say that resource-id is fairly rigid for list items that need dynamic ids.  It would be nice if tag value could be used for locators.

With Espresso, you can use anything (id, tag, hint, content desc, etc.). In general I'd expect the same from other automation frameworks. The problems start when widely used identifiers (ex: resource ids) aren't supported.

@jlipps does uiautomator support finding a view's tag value?  It looked to me like it only supported finding by the name of the tag.

If testID has too much other baggage why can't React Native just have a resourceID prop?
I'm trying to write some uiautomator tests / screenshot automation and React Native's already problematic behaviours (a hard to detect JS loading dialogue and delay before contents are ready) are just made worse by lack of the ability to declare a resource ID to look for when my scenes are loaded.

@dantman resourceID would lead to a lot more Android specific files IMO.

@jsdevel That's fine, we already have other android specific properties. And the whole problem here is that React Native is not supporting Android's resource ID leading to incompatibilities with using Android's own test code.

@dantman sadly, I had support for resourceID ready to go, but it was shut down after a month of back and forth.  See https://github.com/facebook/react-native/pull/9942

@jsdevel whats the tl;dr on this? Is there any plan to support resourceID. I think it's pretty ridiculous it's not supported. Also don't really agree with your comment about how it would lead to more Android specific files. Not allowing the use of a resourceID does this already. It has in the past forced me to create the entire view out of native android code...

resourceID would lead to a lot more Android specific files IMO.

@Brian-Kaplan what I meant was that a new resourceID attribute would lead to more android specific files because resourceID is specific to android.  Ideally testID would be treated as a resource id, but the maintainers didn't want to make that change (see my PR link https://github.com/facebook/react-native/pull/9942#issuecomment-291920319).

On the appium side we'd be +1000 for resource id support, if only because we haven't yet found a good way to get access to view tags from uiautomator, which means we're currently dead in the water.

What's wrong with the suggestion in my previous comment? Unless I've misunderstood, adding a new resourceID attribute means that your RN Views will need to declare both a testID and a resourceID to allow them to be found by Appium on iOS and Android respectively? In which case you might as well just use testID and accessibilityLabel as that achieves exactly the same thing and already works.
I've been testing my RN app using the same Appium test code on both iOS and Android for over a year now. What's different in other setups that are making people 'dead in the water'?

What's different in other setups that are making people 'dead in the water'?

Google's uiautomator (used by Appium) can't find by view tag. resourceID is a standard on Android, react-native omitting support for it is causing problems. There hasn't been a persuasive argument for not supporting resourceID. Only that Facebook isn't interested since they're not directly negatively impacted.

There hasn't been a persuasive argument for not supporting resourceID. Only that Facebook isn't interested since they're not directly negatively impacted.

@bootstraponline this is why I feel open sourcing react-native was mainly a PR gimmick.  If you have an update for react-native and said update would help facebook's use cases internally for their apps, then they will happily merge changes and include them.  The fact that this PR wasn't merged is evidence of that IMO.  Here we are 6 months later and we're still fighting this battle.

@jsdevel whats the tl;dr on this? Is there any plan to support resourceID. I think it's pretty ridiculous it's not supported. Also don't really agree with your comment about how it would lead to more Android specific files. Not allowing the use of a resourceID does this already. It has in the past forced me to create the entire view out of native android code...

The tl;dr is this: Supporting resourceID as proposed in this PR would create too much work internally at facebook so they're not willing to merge it.  Use their selendroid extension script, or the workaround proposed by @jonesdar.

In which case you might as well just use testID and accessibilityLabel as that achieves exactly the same thing and already works.

accessibilityLabel (ie: android:contentDescription) is a human readable label intended to be read out to blind users. Abusing it as a view id on views that should not be read to blind users is unacceptable.

Tags (android:tag) are also unacceptable for test IDs. Tags are not identifiers, they are metadata on views intended to store java objects not IDs.
The official Android documentation on Tags.

Unlike IDs, tags are not used to identify views. Tags are essentially an extra piece of information that can be associated with a view. They are most often used as a convenience to store data related to views in the views themselves rather than by putting them in a separate structure.

Tags are assigned Java objects that are internal to an Android application. They are not available to black box tests (uiautomator). Java objects are scoped to the android app and exposing them outside would likely be a security issue.
They are also not proper ids, when you assign a string that string is just assigned to the view as an Object of data you can fetch out later.
The actual use of tags is for code like this:
Person p = new Person();
p.setName("Ramkailash");
p.setId(2000001);
button1.setTag(p);

IDs (resource-id, android:id) are the correct way of assigning identifiers for both white and black box tests. Unlike tags, IDs are exposed to everyone and clearly intended for identifying views both inside and outside (black box tests) of an app.

Resource IDs are scoped/namespaced, when you look at a view assigned com.example.foobar.app's R.foo id from the outside, it is namespaced to com.example.foobar.app:id/foo.
Resource IDs are available externally to black box tests (see uiautomatorviewer)
Android even has its own built-in IDs: See android.R.id these IDs can be assigned to any view, for example android.R.id.content (which you'll see as resource-id: android:id/content in uiautomatorviewer) is the root view of an Activity and is available to tests

accessibilityLabel (ie: android:contentDescription) is a human readable label intended to be read out to blind users. Abusing it as a view id on views that should not be read to blind users is unacceptable.

Exactly. So I only use it for view ids when creating test builds. It's not ideal to test a slightly different build to what's shipped but I had a choice between ideals and getting stuff done (as is so often the case in software development) so I chose the latter.

IDs (resource-id, android:id) are the correct way of assigning identifiers for both white and black box tests.

I think you can use them. If you create a React Native View and (as per my workaround) set testID and accessibilityLabel to com.example.foobar.app:id/foo then in Appium you can use waitForElementById('com.example.foobar.app:id/foo') and it will find your view on both Android and iOS. Is that close enough to what you're looking for?

@mkonicek We need to revisit this issue. Just because FB manually tests/screenshot tests doesn't mean everyone using their framework needs to also manually test or implement the hacks above to get this working with the defacto automating testing suite. React Native is being used for massive projects right now and the benefits of saving dev time by only coding in both frameworks is being lost by dev time supporting hacks that introduce technical debt. My company has thousands of screens supported by react native right now and testing is our biggest struggle right now. The technical arguments lead by @jsdevel above is clearly in the right. Can we please continue to address this issue, there is obvious demand for it.

I think you can use them. If you create a React Native View and (as per my workaround) set testID and accessibilityLabel to com.example.foobar.app:id/foo then in Appium you can use waitForElementById('com.example.foobar.app:id/foo') and it will find your view on both Android and iOS. Is that close enough to what you're looking for?

@jonesdar this is incorrect.  There's no way to use waitForElementById without resource ID support.  I had it working at one point in this PR.  Oh well :(

@CapitanRedBeard
I totally agree. I introduced accessibilityLabel hack and now test scripts can be run on Android. But setting test ID to accessibility label breaks accessibility feature. So I needed to make a special package for test automation. In general, making a special package is not good idea. I want to test a package which users actually use, rather than special one only for E2E tests.

@jsdevel which part do you think is incorrect? The steps described allow me (and others on this thread) to use waitForElementById to find elements by testID (with strings in any format as far as I can see) on both Android and iOS. Maybe provide some more details about what's failing for you and we might be able to help with where you're going wrong.

@jonesdar are you sure you have .waitForElementById working on android?  testID sets a value in the view object's tag field which .waitForElementById has no access to.  I think what you're meaning to state is that waitForElementByAccessibilityId works with your proposes solution.

@jsdevel Yes I'm sure. I put my test ids into the RN View's testID and accessibilityLabel props. The latter allows waitForElementById to find the View on Android.

There's no way that works unless they changed how testID functions.

testID is not involved on Android - the element gets found due to the test id string being present in the accessibilityLabel prop.
Here's some Appium log output showing a waitForElementById('Email') call on Android finding the correct element:
2017-04-26 09:46:14:035 - info: [HTTP] --> POST /wd/hub/session/89808fa0-53d1-44fa-a64d-c7e8cdaa742b/elements {"using":"id","value":"Email"}
2017-04-26 09:46:14:036 - info: [debug] [MJSONWP] Calling AppiumDriver.findElements() with args: ["id","Email","89808fa0-53d1-44fa-a64d-c7e8cdaa742b"]
2017-04-26 09:46:14:037 - info: [debug] [BaseDriver] Valid locator strategies for this request: xpath, id, class name, accessibility id, -android uiautomator
2017-04-26 09:46:14:037 - info: [debug] [BaseDriver] Valid locator strategies for this request: xpath, id, class name, accessibility id, -android uiautomator
2017-04-26 09:46:14:037 - info: [debug] [BaseDriver] Waiting up to 30000 ms for condition
2017-04-26 09:46:14:038 - info: [debug] [AndroidBootstrap] Sending command to android: {"cmd":"action","action":"find","params":{"strategy":"id","selector":"Email","context":"","multiple":true}}
2017-04-26 09:46:14:050 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Got data from client: {"cmd":"action","action":"find","params":{"strategy":"id","selector":"Email","context":"","multiple":true}}
2017-04-26 09:46:14:051 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Got command of type ACTION
2017-04-26 09:46:14:051 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Got command action: find
2017-04-26 09:46:14:051 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Finding 'Email' using 'ID' with the contextId: '' multiple: true
2017-04-26 09:46:14:051 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Using: UiSelector[RESOURCE_ID=com.tomtom.sportsapp.personal:id/Email]
2017-04-26 09:46:14:051 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] getElements selector:UiSelector[RESOURCE_ID=com.tomtom.sportsapp.personal:id/Email]
2017-04-26 09:46:14:052 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Element[] is null: (0)
2017-04-26 09:46:14:052 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] getElements tmp selector:UiSelector[INSTANCE=0, RESOURCE_ID=com.tomtom.sportsapp.personal:id/Email]
2017-04-26 09:46:14:540 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Using: UiSelector[RESOURCE_ID=android:id/Email]
2017-04-26 09:46:14:541 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] getElements selector:UiSelector[RESOURCE_ID=android:id/Email]
2017-04-26 09:46:14:541 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Element[] is null: (0)
2017-04-26 09:46:14:541 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] getElements tmp selector:UiSelector[INSTANCE=0, RESOURCE_ID=android:id/Email]
2017-04-26 09:46:14:864 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Using: UiSelector[RESOURCE_ID=Email]
2017-04-26 09:46:14:864 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] getElements selector:UiSelector[RESOURCE_ID=Email]
2017-04-26 09:46:14:864 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Element[] is null: (0)
2017-04-26 09:46:14:865 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] getElements tmp selector:UiSelector[INSTANCE=0, RESOURCE_ID=Email]
2017-04-26 09:46:14:868 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Using: UiSelector[DESCRIPTION=Email]
2017-04-26 09:46:14:868 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] getElements selector:UiSelector[DESCRIPTION=Email]
2017-04-26 09:46:14:869 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Element[] is null: (0)
2017-04-26 09:46:14:871 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] getElements tmp selector:UiSelector[DESCRIPTION=Email, INSTANCE=0]
2017-04-26 09:46:14:877 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Element[] is null: (1)
2017-04-26 09:46:14:877 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] getElements tmp selector:UiSelector[DESCRIPTION=Email, INSTANCE=1]
2017-04-26 09:46:14:881 - info: [AndroidBootstrap] [BOOTSTRAP LOG] [debug] Returning result: {"value":[{"ELEMENT":"2"}],"status":0}
2017-04-26 09:46:14:882 - info: [debug] [AndroidBootstrap] Received command result from bootstrap
2017-04-26 09:46:14:883 - info: [debug] [MJSONWP] Responding to client with driver.findElements() result: [{"ELEMENT":"2"}]
2017-04-26 09:46:14:884 - info: [HTTP] <-- POST /wd/hub/session/89808fa0-53d1-44fa-a64d-c7e8cdaa742b/elements 200 848 ms - 89 ```

what does the element look like in uiautomatorviewer?

I fail to see how that works, given that BaseViewManager doesn't do anything fancy with accessibilityLabel.

It's quite simple really - the string in the accessibilityLabel prop ends up in the Android View's content description ('content-desc' field in uiautomatorviewer).
Appium's waitForElementById uses several locator strategies internally (you can see them in the log I posted) and one of them (accessibility id) searches View content descriptions.

Appium's waitForElementById uses several locator strategies internally (you can see them in the log I posted) and one of them (accessibility id) searches View content descriptions.

OK.  I see that now!  That's cool.  So waitForElementById will work, but what about actions like .elementById?

Your tests would likely run faster if you used waitForElementByAccessibilityId instead would it not?

elementById works the same way.
Yes waitForElementByAccessibilityId might be slightly faster - but it wouldn't work on iOS and I don't really want to make my tests platform-specific.

I see.  That's pretty cool in the sense that it works.  I'd say your workaround is probably the best approach  that we have at the moment.  It would be much easier if testID was all that was needed though.  Per the documentation, accessibilityLabel affects the behavior of the view when present, so it's possible the app works during testing when the workaround adds the label, but it doesn't work in production when the label is not present.

@jsdevel Good that you now understand it but painful that I had to spend so much time convincing you. I suggest next time you keep more of an open mind - you could easily have spent a few minutes trying the workaround for yourself rather than repeatedly shooting it down with unhelpful comments like "There's no way that works" just because you didn't understand it.
Agree on the need to get testID working properly though. If I understand correctly uiautomator 2 has view tag support so to me the best solution would be for Appium to add that as a locator strategy in waitForElementById etc.

painful that I had to spend so much time convincing you

It's quite possible that others will have similar questions.  I wasn't trying to be difficult.  Sorry if my questions caused you some consternation.  You helped me to understand something about appium that I haven't seen documented anywhere and for that I am grateful.

If I understand correctly uiautomator 2 has view tag support so to me the best solution would be for Appium to add that as a locator strategy in waitForElementById etc.

In case any testing library authors are reading this, the method is findViewWithTag.

@mkonicek is this still down prioritized?

@jonesdar Thanks for this work-around! Just to point out, I had to use the plural forms of the locator methods for Appium to be able to find my view with the accessibilityLabel on Android: i.e., waitForElementsById instead of waitForElementById and elementsById instead of elementById.
Using the plural form is apparently what tells Appium to try multiple strategies. The clue was in the Appium server debug logs. When I used the singular form, the log had the equivalent of
 [debug] [AndroidBootstrap] Sending command to android: {"cmd":"action","action":"find","params":{"strategy":"id","selector":"Email","context":"","multiple":false}}
The "multiple":false prompted me to explore this a bit and I finally found the answer here

@mkonicek Are there any plans to proceed with this issue?
Because tag is not available via Appium on Android (and will be not available in foreseeable futurte) due to UIAutomator2 limitations (https://github.com/appium/appium/issues/6025#issuecomment-322266065)
and only AccessibilityLabel is left and given this is not an id and we are going to use AccessibilityLabel for, actually, accessibility there is no viable way to test react-native applications on Android.

@mkonicek any ETA for when FB might open-source the internal e2e framework?

Hey everyone, so sorry about the long radio silence about this. I left fb in the meantime and went traveling for 4 months, joined a startup where I'm doing some native Android dev for now, currently playing with integrating React Native to an existing native app :)
I feel very sorry about closing this PR and seeing it disappointed so many people. I thought someone from the community would provide a way to look up elements by Android view tags like we did at fb and the issue would be solved. It looks like it's harder to add support to Appium to this than I thought.
At the same time, I'm glad there the workaround by @jonesdar (https://github.com/facebook/react-native/pull/9942#issuecomment-266992184). It looks good and I'd use it when testing my app with Appium. I'll copy it hear to make it easier to discover (at the end of the comments section). Quoting @jonesdar:

I defined a testProps(id) function which returns an object {testID: id, accessibilityLabel: id}.
It's used in all our RN views e.g.
<View {...testProps('idForThisView')}>
Appium can then find elements by id on both iOS and Android. Yes, the accessibilityLabel is user-visible but testProps is conditional on build type so we only include these props for a test build anyway.
It means we're not quite testing with the exact build we ship, but it's worked well for the last 9-10 months.

Worth pointing out that the workaround needs a few tweaks on newer versions of Android.
Firstly you'll need to specify automationName: 'uiautomator2' in Appium's desired capabilities (I think the default 'uiautomator' has been deprecated from Android 5.0 onwards).
Then you'll notice that waitForElementById, elementById etc. no longer do multiple locator strategy fallbacks (so elementById won't fall back to elementByAcessibilityId etc.) - I fixed that as follows:
    if ('android' === process.env.APPIUM_PLATFORM) {
      // uiautomator2 doesn't seem to do multiple locator strategy fallbacks
      // so map id to accessibility id directly
      wd.addPromiseChainMethod('waitForElementById', id => {
        return this._driver.waitForElementByAccessibilityId(id);
      });

      wd.addPromiseChainMethod('elementById', id => {
        return this._driver.elementByAccessibilityId(id);
      });

      wd.addPromiseChainMethod('elementByIdOrNull', id => {
        return this._driver.elementByAccessibilityIdOrNull(id);
      });

      wd.addElementPromiseChainMethod('elementById', function() {
        return this.elementByAccessibilityId(id);
      });
    }

i.e. centrally map waitForElementById() to waitForElementByAccessibilityId() etc. - to ensure that Appium finds the testIDs we've put into the accessibilityLabels.
Note that you could just use the accessibility id methods on Android and the id methods on iOS but I've always used the same test code on both platforms and I don't want it to diverge now.
I think I read somewhere that you can do multiple locator strategy fallbacks by using plurals (waitForElementsById, elementsById) but I haven't tried that - and it would still require a global find/replace in all test code (or a central mapping as above) anyway to get existing tests working again.
On the plus side, uiautomator2 seems to run my tests twice as fast as uiautomator.

Worth pointing out that the workaround needs a few tweaks on newer versions of Android.
Firstly you'll need to specify automationName: 'uiautomator2' in Appium's desired capabilities (I think the default 'uiautomator' has been deprecated from Android 5.0 onwards).
Then you'll notice that waitForElementById, elementById etc. no longer do multiple locator strategy fallbacks (so elementById won't fall back to elementByAcessibilityId etc.) - I fixed that as follows:
if ('android' === process.env.APPIUM_PLATFORM) {
  // uiautomator2 doesn't seem to do multiple locator strategy fallbacks
  // so map id to accessibility id directly
  wd.addPromiseChainMethod('waitForElementById', id => {
    return this._driver.waitForElementByAccessibilityId(id);
  });

  wd.addPromiseChainMethod('elementById', id => {
    return this._driver.elementByAccessibilityId(id);
  });

  wd.addPromiseChainMethod('elementByIdOrNull', id => {
    return this._driver.elementByAccessibilityIdOrNull(id);
  });

  wd.addElementPromiseChainMethod('elementById', function() {
    return this.elementByAccessibilityId(id);
  });
}

i.e. centrally map waitForElementById() to waitForElementByAccessibilityId() etc. - to ensure that Appium finds the testIDs we've put into the accessibilityLabels.
Note that you could just use the accessibility id methods on Android and the id methods on iOS but I've always used the same test code on both platforms and I don't want it to diverge now.
I think I read somewhere that you can do multiple locator strategy fallbacks by using plurals (waitForElementsById, elementsById) but I haven't tried that - and it would still require a global find/replace in all test code (or a central mapping as above) anyway to get existing tests working again.
On the plus side, uiautomator2 seems to run my tests twice as fast as uiautomator.

I'd happily get this working again 😄  any takers from the RN team?

I've written a babel plugin to address this issue in the meantime. The idea is to add a property accessibilityLabel every time a testId jsx property is found. Essentially it'll allow you to provide meaningful accesibilityLabels in your application and on an Android specific build replace this by the defined testIDs.
https://github.com/jribeiro/babel-plugin-jsx-property-alias
Hope it helps

I realize that my pull request is very similar to this pull request.

@lightboys22 I'm sorry that you went down this road.  I feel your pain 😢

Good

We use Appium to test our applications and I was able to solve this problem very elegantly with react-native-testid.

@tylermurry react-native-testid will change the accessibilityLabel on Android platform.  Our accessibilityLabel won't be unique.

A copy and paste solution using Espresso and the solution from #9942 in this article:
Espresso testing React Native

I know this ticket is old and many people have found suitable workarounds, but in case anyone still cares (and is actually using accessibilityLabel for accessibility like one should 😉), I've put up a super simple PR that should fix this. cc @jsdevel @lightboys22

@jdeff
I am on react-native 0.62. So I took your changes(commit #29610)) locally to node_modules (path:ReactAndroid/src/main/java/com/facebook/react/uimanager/ReactAccessibilityDelegate.java ) and tried to test my application with UI Automator view and unable to get the vlaues for resource-id. Its always empty.
Am I missing something here ?

Same, resource-id is still empty, any solution yet for this?


Batch translog sync/upload per x ms for remote-backed indexes

Description
Translog sync takes care of local fsync and translog upload onto remote store. Currently, there is implicit buffering that happens as the remote store upload is a time consuming operation. However, every upload adds extra cost of network interaction along with the actual file upload. If we can buffer for a pareto-optimal duration, then we can save on the additional network interaction costs and overall achieve lower latencies and higher indexing throughput in comparison to non-buffered approach. There is also a delay optimisation in place that make sure that if the upload took considerable time, then schedule the next run with a decreased interval maintaining the overall buffer interval in check.
Issues Resolved
This solves #5692
Check List

[x] New functionality includes testing.

[x] All tests pass

[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff
[x] Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #5854 (776d2a2) into main (32dd9e2) will decrease coverage by 0.01%.
The diff coverage is 71.56%.

@@             Coverage Diff              @@
##               main    #5854      +/-   ##
============================================
- Coverage     70.88%   70.86%   -0.02%
+ Complexity    58720    58715       -5
============================================
  Files          4768     4769       +1
  Lines        280575   280664      +89
  Branches      40514    40523       +9
============================================
+ Hits         198881   198890       +9
- Misses        65334    65435     +101
+ Partials      16360    16339      -21

Impacted Files
Coverage Δ

...pensearch/common/settings/IndexScopedSettings.java
100.00% <ø> (ø)

...search/index/translog/InternalTranslogFactory.java
100.00% <ø> (ø)

...anslog/RemoteBlobStoreInternalTranslogFactory.java
75.00% <ø> (ø)

...earch/index/translog/WriteOnlyTranslogManager.java
66.66% <ø> (ø)

...in/java/org/opensearch/index/shard/IndexShard.java
69.77% <45.45%> (-0.16%)
:arrow_down:

...n/java/org/opensearch/index/engine/NoOpEngine.java
63.51% <50.00%> (+0.49%)
:arrow_up:

...va/org/opensearch/index/engine/ReadOnlyEngine.java
73.68% <50.00%> (-0.56%)
:arrow_down:

...search/indices/recovery/RecoverySourceHandler.java
77.98% <50.00%> (-0.37%)
:arrow_down:

...mmon/util/concurrent/BufferedAsyncIOProcessor.java
65.62% <65.62%> (ø)

.../main/java/org/opensearch/index/IndexSettings.java
85.63% <75.00%> (-0.24%)
:arrow_down:

... and 485 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

https://github.com/opensearch-project/OpenSearch/issues/5986 - We will make the index.remote_store.translog.buffer_interval dynamic after this issue.

Credits for some of the code - Ashwin Pankaj, Laxman Muttineni

Please do add them to the git commit message by adding the co-author trailer: Co-authored-by: name<EMAIL_ADDRESS>

Credits for some of the code - Ashwin Pankaj, Laxman Muttineni

Please do add them to the git commit message by adding the co-author trailer: Co-authored-by: name<EMAIL_ADDRESS>
Thanks for shedding light on this. I have added them as co-authors in the last commit. Please let me know if this does not work.


[otl] Update to 4.0.455

Update otl to latest release revision 4.0.455
There is no features need to test locally.

Cools! Thanks @PhoebeHui :D


AnnotationViewer settings doesn't use global settings

Prerequisites
Put an X between the brackets on this line if you have done all of the following:

[X] Reproduced the problem or exposed a new need
[X] Checked the github existing issues

Description

Function drawPolyLines from drawUtils should use fillOpacity settings parameters instead of static values when renderering on canvas.
Steps to Reproduce

Create a new <AnnotationViewer />
Set settings props with settings={{ highlightedShapeOptions: { fillOpacity: 100 }, shapeOptions: { fillOpacity: 100 }}}
Canvas predictions shapes still have an opacity of 20% and 50% on hovering shape

Expected behavior:
The shape is fully opaque
Actual behavior:
Settings are not used and opacity is static
Reproduces how often:
100% of the times
Versions

<EMAIL_ADDRESS>Additional Information

Hi Nicolas, thank you for reporting this issue.
I marked it as a good first issue, as well as an enhancement.
We'll for sure work on this in the future, but feel free to submit a pull request if you want this feature in the SDK sooner.

Hello,
I tried to make a pull request to allow use of the settings in drawing util but it might break something in existing integrations (no default opacity is set by default when drawing).
Tell me what you think about it.

Hello Nicolas,
Thank you for your PR. Dynamic settings are not fully supported yet, this feature will be included soon in the next release. We cannot accept this PR as it may end up breaking other parts of the code.
You can always change static values directly in your repo to achieve the expected result.


ui-mask does not handle 0 as integer

When a number mask is passed to the directive and 0 as a integer is passed the ng-model it clears the input. If 0 is a string the values still displays.
http://plnkr.co/edit/sII1hKod5CqbgzPGCiiL?p=preview

UI.Utils modules was split in individuals repositories. If still valid, please consider re-submitting on its dedicated repository: https://github.com/angular-ui/ui-mask
See the README for details.


24040 Fix Alteration of Company Type Options for BEN/CBEN

Issue #: /bcgov/entity#24040
Description of changes:

remove CC option from allowed business alteration types for BEN businesses
remove CCC option from allowed business alteration types for CBEN businesses

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the bcrs-entities-create-ui license (Apache 2.0).

/gcbrun

Temporary Url for review: https://business-edit-dev--pr-593-nzrgwlvx.web.app

Numbered BEN business: https://business-edit-dev--pr-593-nzrgwlvx.web.app/BC0883647/alteration?accountid=3627
Numbered CBEN business: https://business-edit-dev--pr-593-nzrgwlvx.web.app/C9900823/alteration?accountid=3627
Named BEN business: https://business-edit-dev--pr-593-nzrgwlvx.web.app/BC0883657/alteration?accountid=3627
Named CBEN business: https://business-edit-dev--pr-593-nzrgwlvx.web.app/C9900826/alteration?accountid=3627


Wrong Data - maybe an issue with Shelly 3EM Code

Hey
i have a balcony pv with 2 x 410W modules and a Hoymiles HM-800 as PV Inverter. works great, opendtu works like a charm.

I have no multigrid II
Hoymiles HM800 at L3 conncted
Raspi4 as CerboGX with Venus OS
Shelly 3 EM installed in the Mainline, in FRONT af the whole house - and installed the code in VenusOS for it

Now in my oppinion something is mathematical wrong. See the picture
i get 40W from my Hoymiles Inverter - that shows as -40W, thats correct, because the shelly is measuring negative, if im bring in power, that i dont use.

i confd the opendtu code as pvinverter. because its doing this. it on L3 and inverting fine.
[INVERTER0]
Phase=L3
DeviceInstance=34
AcPosition=1
Servicename=com.victronenergy.pvinverter
Shelly is confed like that:
[DEFAULT]
AccessType = OnPremise
SignOfLifeLog = 1
CustomName = Shelly 3EM
DeviceInstance = 40
Role = grid
Position = 0
LogLevel=ERROR
[ONPREMISE]
Host=<IP_ADDRESS>
Username=
Password=
L1Position = 1
if im put opendtu in at ac pos 0 - it wont show up (plz why?), if i put it as ac out 1 - it works, but for the cerbo its a load, so it puts that -40W to +40W at the load end.
the shelly is confed on grid40
So something is wrong here - maybe with the shelly code, or yours, i dont know. or im wrong :P

it works fine and well with a real existing multiplus, also rather check the values you see under the individual devices in Venus Console.
All Display on Venus Console or VRM Console is out of our control, as we write only to dbus according to documentation. Victron is in charge and control for the rest.


[arc-docs] Add a small section on deinits.

This adds a section to the ARC optimization document that explains the semantics of deinit that are important to the optimizer. It is meant to eliminate confusion in this area through clear documentation and a nice example.

@atrick How does this look?

@swift-ci Please smoke test

Thanks. I think this is useful to have in the ARC optimizer doc. It's on me to figure out how to specify those semantics, but I don't want to do that right now, and at least this provides a pretty good intuition.


Add 'statusKnown' to firebase-auth

Description
We need a way to know if authentication is still in progress.  For example, if we are using carbon-routing, we want to defer any routing events until we determine whether or not the user is authenticated (so we know to redirect them to login on the actual destination page).  If the user has previously been logged in, and returns to the page (page refresh), there is a delay before the persisted user object is loaded and set. We'd like to check this state before performing any routing.
Expected Behavior
When true, login status can be determined by checking user property.

Looking at the code, what is statusKnown an indication of?  If it suggests that you can’t rely on user alone to know whether a user is signed in (which is what the field comment suggests), then the implementation of _computeSignedIn (!!user) doesn’t follow that logic.

You can rely on the user object to know if a user is signed in (when you have a user object). But you can't rely on it know if either a user is signed out, or if we just don't know either way yet. _computeSignedIn makes no distinction between those 2 states, and as far as I can tell it isn't really intended to. It returns true if you are definitely signed in, and false otherwise.


DST

Hi,
Thanks for the nice work. As the proposed model is based on TripPy when evaluating dialogue state tracking, I wonder how the MultiWOZ is preprocessed. I found that TripPy may change some ground-truth labels using the original preprocessing script (e.g., the time-slot value "10:30" may be changed to "10" only.), so if convenient, could you please do a simple comparison between the ground-truth labels before and after the preprocessing? Since you are launching a leaderboard, I hope that the evaluation could be as precise as possible. Thanks!

Thanks for the note. We will look into that effect once we get some time. In the meantime, please keep us posted if you make any interesting observations based on this!


Gh-259 GraphFrame and PageRank added to Python Shell

Added the GetGraphFrameOfElements, and PageRank operations to the Python shell, as well as tests for both.

Closing until these operations have been added to Gaffer.


Add icons to hourly weather bar

Is your feature request related to a problem? Please describe.
Card works as intended, but often the weather conditions aren't displayed.  In this case it would be beneficial to have an icon displayed to give indication to what the color represents.
Describe the solution you'd like
An option to display icons on the hourly weather bar.
Describe alternatives you've considered
A smaller font to show weather conditions could help, but icons seem more elegant.

How do you feel about an icon mode? That is, a config option to show icons instead of text labels. The text labels will only show when a segment is >= 120px wide, but I could make icons show when a segment is as small as around 40px.
The way the code is written, it's easier to have it be either text labels OR icons. Would be harder and more brittle to support text labels for wider space and icons for smaller space.
Also note that I may also implement #8 with tooltip, so that may also help here.
Unless folks feel strongly about having both text and icons, I'll stick with the either/or plan described above.

Icon mode would be great!

FWIW, I'm having the same problem (weather changes too frequently around here). An icon mode would be great, and would also work well for smaller wall displays too.