The Wayback Machine - https://web.archive.org/web/20200906013839/https://github.com/web-push-libs/web-push-php/pull/185
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return results as a \Generator #185

Merged
merged 7 commits into from Nov 27, 2018

Conversation

@t1gor
Copy link
Contributor

t1gor commented Sep 21, 2018

As discussed in #183:

  • provide a mapped request/response report when sending a bunch of messages
  • utilize the \Generator object for better performance
  • add some documentation on running the tests for making contributions easier
  • update documentation on sending requests in bulk
@t1gor
Copy link
Contributor Author

t1gor commented Sep 21, 2018

I guess I should also provide some kind of a migration path and a note on update ... will do shortly.

@Minishlink
Copy link
Member

Minishlink commented Sep 22, 2018

Thanks @t1gor! You can post it as a comment on this PR and I'll include it in the release notes :)

Copy link
Member

Minishlink left a comment

Great job! Thanks a lot! 🎉

@Minishlink
Copy link
Member

Minishlink commented Nov 2, 2018

@t1gor Do you have some time to write some migration path? If not tell me please :)
Btw I really appreciate your help on the issues, thanks!

@t1gor
Copy link
Contributor Author

t1gor commented Nov 5, 2018

@Minishlink sorry, totally lost it in a daily routine. Sure, the migration path should be something like the following:

====================================

Breaking changes

The way you handle the results of the flush() method should be changed. Since X.X.X (embedd version here) the flush always returns a Generator object. This mean that you can still iterate over it, but you wouldn't be able to store it, at least not as-is. Using the example from the docs, the responses would now look different:

PLEASE NOTE:
\Generator is returned even if you only send one message.

BEFORE:

$res = [
    [ // first notification (failed)
        'success' => false,
        'endpoint' => $theEndpointToDeleteInYourDatabaseIfExpired,
        'message' => $responseMessage,
        'statusCode' => $responseStatusCode,
        'headers' => $responseHeaders,
        'content' => $responseContent, // you may have more infos here
        'expired' => $isTheEndpointWrongOrExpired,
    ],
    [ // second notification (succeeded)
        'success' => true,
    ],
    [ // third notification
        ...
    ], ...
];

AFTER:

var_dump($res); // \Generator

/** \Minishlink\WebPush\MessageSentReport */
foreach ($res as $result) {
    // you now have access to request & response objects

    /** @var \Psr\Http\Message\RequestInterface $request */
    $request = $result-> getRequest();
    /** @var \Psr\Http\Message\ResponseInterface $response */
    $response = $result->getResponse();

    if ($result->isSuccess()) {
        // process successful message sent
        $logger->log('Notification with payload %s successfully sent for endpoint %s.' [
            json_decode((string) $response->getBody()),
            $result->getEndpoint()
        ]);
    } else {
        // or a failed one - check expiration first
        if ($result->isSubscriptionExpired()) {
            // this is just an example code, not included in library!
            $db->markExpired($result->getEndpoint());
        } else {
            // process faulty message
            $logger->log('Notification failed: %s. Payload: %s, endpoint: %s' [
                $result->getReason(),
                json_decode((string) $response->getBody()),
                $result->getEndpoint()
            ]);
        }
    }
}

====================================

This should do the job. Please let me know if I forgot something.

Cheers.

* @return \Generator
* @throws \ErrorException
*/
public function flush(?int $batchSize = null) : \Generator

This comment has been minimized.

@Spomky

Spomky Nov 5, 2018

Contributor

I prefer \iterable instead of \Generator. But it will also work that way.
Ref. http://php.net/manual/en/language.types.iterable.php

This comment has been minimized.

@t1gor

t1gor Nov 5, 2018

Author Contributor

Well, \iterable suggests that you can loop over the object, when the \Generator actually saves some memory for the interpreter, as far as I understand the difference. In this exact case, don't think it's much of a difference any way - the main cause of this pull request is to add possibility to match the request and response directly in flush() results.

This comment has been minimized.

@Spomky

Spomky Nov 5, 2018

Contributor

\iterable is just a pseudo type and generators implement that type.
See ex. 4 of the link I gave.

Having \iterable instead of \Generator in the method signature won't change anything regarding the memory saving or the behaviour of the yield used in the method.
You will iterate the same way and foreach ($res as $result) { in your example will still be valid.

From my POV, it is preferable to indicate pseudo-types as return types instead of a concrete/specific type. As I mentioned, it won't change anything, but it will be easier to mock or override the class with the later.

This comment has been minimized.

@t1gor

t1gor Nov 5, 2018

Author Contributor

but it will be easier to mock or override the class with the later.

Fair enough. Will try to change in nearest future.

This comment has been minimized.

@t1gor

t1gor Nov 7, 2018

Author Contributor

Change applied.

This comment has been minimized.

@Spomky

Spomky Nov 7, 2018

Contributor

Excellent!
Thank you.

@Spomky
Spomky approved these changes Nov 7, 2018
@t1gor
Copy link
Contributor Author

t1gor commented Nov 9, 2018

@Minishlink would you be able to merge this any time soon? The migration path provided in the thread above.

@Minishlink
Copy link
Member

Minishlink commented Nov 11, 2018

@t1gor Thanks! Sure, I'll try to fix the test suite before though. Let's say if I haven't succeeded by next Saturday night, I'll test manually and merge it :)

@t1gor
Copy link
Contributor Author

t1gor commented Nov 12, 2018

@Minishlink
Copy link
Member

Minishlink commented Nov 25, 2018

@t1gor Oops, 1 week late, sorry :o
Travis tests are fixed though! Could you rebase please?

@t1gor t1gor force-pushed the t1gor:feature-return-results branch from 4c181c3 to 7ab1771 Nov 26, 2018
@t1gor
Copy link
Contributor Author

t1gor commented Nov 26, 2018

@Minishlink really not sure with the re-base :/ could you please check it? Seems like something went wrong ...

@Minishlink
Copy link
Member

Minishlink commented Nov 26, 2018

@t1gor Looks like it's good except for a "Vagrantfile" that appears?

@t1gor
Copy link
Contributor Author

t1gor commented Nov 26, 2018

@Minishlink my bad, removed.

@Minishlink Minishlink merged commit eac6697 into web-push-libs:master Nov 27, 2018
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@Minishlink
Copy link
Member

Minishlink commented Nov 27, 2018

@t1gor This is in v5 :) Can you do a quick update of https://github.com/web-push-libs/web-push-php#server-errors please? You either forgot to edit it or the rebase cut it :o

@t1gor
Copy link
Contributor Author

t1gor commented Nov 28, 2018

@t1gor This is in v5 :) Can you do a quick update of https://github.com/web-push-libs/web-push-php#server-errors please? You either forgot to edit it or the rebase cut it :o

Seems like I did forget, thanks for pointing out. Would you like another merge request?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.
Morty Proxy This is a proxified and sanitized view of the page, visit original site.