@cxpinsight/react-native 0.10.0 → 0.11.0

package/CHANGELOG.md

@@ -1,5 +1,105 @@
 # Changelog
 
+## 0.11.0
+
+Requires `@cxpinsight/survey-spec@^0.6.0`.
+
+### Fixed
+
+- **A "not" condition could never be true.** An author writing `not {plan} =
+  "pro"` got a rule that read correctly and matched nothing, because `not` was
+  applied to the answer before the comparison instead of to the comparison. The
+  question it guarded either never appeared or never went away.
+
+  It also meant two answers to the same question: the server works branching
+  logic out in advance now, and the server had always read this correctly, so
+  the same condition could resolve one way from the compiled version and the
+  other way from the written one.
+
+- **Two settings the builder accepted and nothing applied.** A pattern set as
+  `regex` on a question was read by nothing at all — the same pattern written as
+  a rule was enforced, so identical intent behaved differently depending on how
+  it was entered. And a minimum or maximum on a number question never applied,
+  because the answer arrives as text and the check only looked at numbers.
+
+  Both now behave the way the builder implies. Neither is enforced any
+  differently on the server, where an author-supplied pattern against a
+  respondent's answer is a risk to every customer rather than to one.
+
+### Note
+
+Release notes for 0.10.0 were written after that version was published, so they
+appear in this package for the first time here. Nothing about 0.10.0 changed.
+
+## 0.10.0
+
+Requires `@cxpinsight/survey-spec@^0.5.1`.
+
+### Fixed
+
+- **Six targeting operators were equality tests in disguise.** The trigger
+  engine implemented 8 of the 14 operators and quietly treated the rest as
+  `equals`. So `in`, `not_in`, `not_contains`, `starts_with`, `ends_with` and
+  `not_exists` behaved correctly on web and almost never fired on mobile, from
+  the same rule, with nothing anywhere reporting the difference.
+
+  An author targeting `path starts_with /checkout` got an interaction that
+  appeared on a website and stayed silent in the app — `/checkout/payment` is
+  not equal to `/checkout`. All six now work, and an operator this SDK does not
+  recognise fails closed and is reported through `getUnknownTokens()` instead of
+  being guessed at.
+
+- **An action's destination is resolved before it is opened.** A button's
+  destination is written as a template — `myapp://cart/{{orderId}}` — and the
+  reference was being handed to the renderer as written, so the button opened a
+  literal `{{orderId}}` instead of the customer's cart. If a reference resolves
+  to nothing, the button now opens nothing rather than sending someone to a
+  broken address; the answer is still recorded either way.
+
+- **Two ways question text could show a respondent things it should not.**
+  `{{constructor}}` printed JavaScript internals onto the screen, and
+  `{{q.answer}}` for a matrix, panel or file question printed the raw answer
+  object — including every field it held. Both now render as empty text.
+
+### Added
+
+- **Conditions arrive already compiled.** The server now works out each
+  question's show/hide logic once and sends the result with the survey, so this
+  SDK follows a decision instead of re-reading the rule on every answer. Surveys
+  served without it fall back to the previous behaviour, so nothing changes
+  until a customer's surveys are served the new way.
+
+- **"Remind me later."** A choice that closes the interaction and records a skip
+  rather than an answer — so it comes back after the wait and gives up after the
+  last try. Built as an ordinary choice it did the opposite: it recorded a
+  decision and retired the interaction for good, meaning the one button whose
+  purpose is to bring it back guaranteed it never would.
+
+- **Four interaction purposes** — ask, notify, offer and comply — each with an
+  ending that matches what was asked, rather than thanking someone for answering
+  a question that was never put to them.
+
+- **The SDK reports what it can actually run.** It now declares its supported
+  question types and operators, so a survey using something this version cannot
+  render is visible as a version gap rather than as a blank space on a phone.
+
+### Changed
+
+- Question rendering is driven by the compiled primitive rather than the
+  question type, which is what lets a new question type reach mobile without an
+  SDK release.
+
+## 0.9.0
+
+### Added
+
+- **The implied question type**, which is what lets Notify, Offer and Comply
+  render at all. An implied question's choices *are* its action buttons, so the
+  labels an author writes — "Activate discount" / "No thanks", "I agree &
+  continue" / "Decline" — are the labels the respondent presses. The three
+  interaction kinds had been seeded but marked coming soon, because there was no
+  question type meaning "the answer is which action you took".
+
 ## 0.8.0
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cxpinsight/react-native",
-  "version": "0.10.0",
+  "version": "0.11.0",
   "description": "CXPinsight React Native SDK — engagement tracking, native survey modals & visual setup mode",
   "main": "lib/index.js",
   "types": "lib/index.d.ts",
@@ -11,7 +11,7 @@
     "test": "node --test test/*.test.js"
   },
   "dependencies": {
-    "@cxpinsight/survey-spec": "^0.5.1"
+    "@cxpinsight/survey-spec": "^0.6.0"
   },
   "peerDependencies": {
     "@react-native-async-storage/async-storage": ">=1.19.0",