You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What this shim does is fairly simple if you go line by line:
98
98
99
-
. makes sure that jQuery is loaded before angular (which actually runs the shim above)
99
+
. makes sure that jQuery is loaded before angular (which actually runs the shim)
100
100
. load the angular.js file from the node_modules directory
101
101
. load the angular-elastic plugin, a plugin we want to always be included whenever we import angular
102
102
. use the `ui/modules` module to add the module exported by angular-elastic as a dependency to the `kibana` angular module
103
-
. finally, export the window.angular variable. This means that writing `import angular from 'angular';` will properly set the angular variable to the angular library, rather than undefined which is the default behavior.
103
+
. finally, export the window.angular variable. This means that writing `import angular from 'angular';` will properly set the angular variable to the angular library, rather than undefined which is the default behavior.
Copy file name to clipboardExpand all lines: docs/developer/plugin/development-plugin-feature-registration.asciidoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -175,7 +175,7 @@ init(server) {
175
175
}
176
176
-----------
177
177
178
-
Unlike the Canvas example above, Dev Tools does not require access to any saved objects to function. Dev Tools does specify an API endpoint, however. When this is configured, the Security plugin will automatically authorize access to any server API route that is tagged with `access:console`, similar to the following:
178
+
Unlike the Canvas example, Dev Tools does not require access to any saved objects to function. Dev Tools does specify an API endpoint, however. When this is configured, the Security plugin will automatically authorize access to any server API route that is tagged with `access:console`, similar to the following:
Copy file name to clipboardExpand all lines: docs/developer/plugin/development-plugin-localization.asciidoc
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -68,7 +68,7 @@ This outputs a `en.json` file inside the `translations` directory. To localize o
68
68
Checking i18n does the following:
69
69
70
70
* Checks all existing labels for violations.
71
-
* Takes translations from `.i18nrc.json` and compares them to the messages extracted and validated at the step above and:
71
+
* Takes translations from `.i18nrc.json` and compares them to the messages extracted and validated.
72
72
** Checks for unused translations. If you remove a label that has a corresponding translation, you must also remove the label from the translations file.
73
73
** Checks for incompatible translations. If you add or remove a new parameter from an existing string, you must also remove the label from the translations file.
Full details are {repo}tree/master/packages/kbn-i18n#vanilla-js[here].
113
113
114
114
[float]
115
-
===== i18n for React
115
+
===== i18n for React
116
116
117
117
To localize strings in React, use either `FormattedMessage` or `i18n.translate`.
118
118
@@ -138,7 +138,7 @@ Full details are {repo}tree/master/packages/kbn-i18n#react[here].
138
138
139
139
140
140
[float]
141
-
===== i18n for Angular
141
+
===== i18n for Angular
142
142
143
143
You are encouraged to use `i18n.translate()` by statically importing `i18n` from `@kbn/i18n` wherever possible in your Angular code. Angular wrappers use the translation `service` with the i18n engine under the hood.
Copy file name to clipboardExpand all lines: docs/developer/pr-review.asciidoc
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -67,7 +67,7 @@ Enhancements are pretty much always going to have extensive unit tests as a base
67
67
[float]
68
68
=== Product level review
69
69
70
-
Reviewers are not simply evaluating the code itself, they are also evaluating the quality of the user-facing change in the product. This generally means they need to check out the branch locally and "play around" with it. In addition to the "do we want this change in the product" details from above, the reviewer should be looking for bugs and evaluating how approachable and useful the feature is as implemented. Special attention should be given to error scenarios and edge cases to ensure they are all handled well within the product.
70
+
Reviewers are not simply evaluating the code itself, they are also evaluating the quality of the user-facing change in the product. This generally means they need to check out the branch locally and "play around" with it. In addition to the "do we want this change in the product" details, the reviewer should be looking for bugs and evaluating how approachable and useful the feature is as implemented. Special attention should be given to error scenarios and edge cases to ensure they are all handled well within the product.
71
71
72
72
73
73
[float]
@@ -107,7 +107,7 @@ Conflicting opinions between reviewers and authors happen, and sometimes it is h
107
107
108
108
Whether or not a bit of feedback is appropriate for a pull request is often dependent on the motivation for giving the feedback in the first place.
109
109
110
-
_Demanding_ an author make changes based primarily on the mindset of "how would I write this code?" isn't appropriate. The reviewer didn't write the code, and their critical purpose in the review process is not to craft the contribution into a form that is simply whatever they would have written if they had. If a reviewer wants to provide this type of feedback, they should qualify it as a "nit" as mentioned in the nitpicking section above to make it clear that the author can take it or leave it.
110
+
_Demanding_ an author make changes based primarily on the mindset of "how would I write this code?" isn't appropriate. The reviewer didn't write the code, and their critical purpose in the review process is not to craft the contribution into a form that is simply whatever they would have written if they had. If a reviewer wants to provide this type of feedback, they should qualify it as a "nit" as mentioned in the nitpicking section to make it clear that the author can take it or leave it.
111
111
112
112
Inflammatory feedback such as "this is crap" isn't feedback at all. It's both mean and unhelpful, and it is never appropriate.
0 commit comments